Author Archives: Brent Huston

About Brent Huston

I am the CEO of MicroSolved, Inc. and a security evangelist. I have spent the last 20+ years working to make the Internet safer for everyone on a global scale. I believe the Internet has the capability to contribute to the next great leap for mankind, and I want to help make that happen!

May’s Touchdown Task: Egress Audit

Posted on by
4

The touchdown task for May is a quick and dirty egress filtering audit. Take a look at your firewalls and make sure they are performing egress filtering (you do this, right? If not, make it happen now ~ it’s the single most effective defense against bot-nets). Once you know egress is in place, give a once over to the firewall rules that enforce it. Make sure they are effective at blocking arbitrary ports, outbound SSH, outbound VPN connections, etc. Verify that any exposed egress ports are to specific IPs or ranges. If you find any short comings, fix them.

Also take a look and make sure that violations of the firewall rules are being alerted on, so your team can investigate those alerts as potential infection sites. 

Lastly, check to make sure that you have egress controls for outbound web traffic. You should be using an egress proxy for all HTTP and HTTPS traffic. Yes, you should be terminating SSL and watching that traffic for signs of infection or exfiltration of sensitive data. Take a few moments and make sure you have visibility into the web traffic of your users. If not, take that as an immediate project. 

That’s it. This review should take a couple of hours or so to complete. But, the insights and security enhancements it can bring are HUGE. 

Until next month, thanks for reading and run for the goal line!

Fuzzing Optical Smart Meters with ProtoPredator

Posted on by
6

PPClawsWords1

Our team has been working hard in the lab, once again testing the optical implementations of a variety of smart meters. Using our proprietary in-house developed tool, called ProtoPredator for Smart Meters, we have been doing full fuzzing of optical protocol implementations. 

Our tool makes this process easy and reproducible. It also provides for easy regression testing and fix validation through session replays. 

One of the things that makes ProtoPredator so cool is that it includes both arbitrary conversations with the meters in addition to canned sessions, making much more flexible in the hands of a knowledgeable user. You can easily use this feature to perform more nuanced validation of the protocols, testing things like sequence errors, poor trust, error recovery, etc. 

While ProtoPredator is still tied to the optical coupler speed and the inherent speed of the protocols in use, testing with it makes validation of the optical ports more effective than other more traditional approaches. Additionally, you can use multiple seats of ProtoPredator in parallel to decrease the overall testing and validation time, especially since the “brain files” and packet sessions are easily interchangeable amongst installations.

The easy to use GUI also means less frustration and more time on task for most users. It lets the testers spend less time on mundane tasks like serial configuration and hand crafting packets and more time on security testing, protocol analysis and bug hunting.

To find out more about ProtoPredator, or to discuss having our lab give your smart meters a look over, get in touch. Info(at)micro solved(dot)com will get you a prompt response. As always, thanks for reading! 

64 Bit OS Reminder for HoneyPoint

Posted on by
2

Just a quick note to help folks who are using HoneyPoint, regardless of version. If you are having trouble with execution on a 64 bit operating system, remember that HoneyPoint binaries are 32 bit. To run them on 64 bit OS’s, you need ensure that you have the 32 bit compatibility tools installed.

For Windows, read this.

For Ubuntu, read this.

For other operating systems, please consult your operating system vendors’ documentation. If we can be of any assistance, please contact your HoneyPoint support person.

Thanks!

Aaron Bedra on Building Security Culture

Posted on by
9

Our good friend, Aaron Bedra, posted a fantastic piece at the Braintree Blog this morning about building a security culture. I thought the piece was so well done that I wanted to share it with you.

Click here to go to the post.

The best part of the article, for me, was the content about finding creative ways to say yes. IMHO, all too often, infosec folks get caught up in saying no. We are the nay sayers, the paranoid brethren and the net cops. But, it doesn’t have to be that way. It might take a little (or even a LOT) of extra work, but in many cases ~ a yes is possible ~ IF you can work on it and negotiate to a win/win point with the stakeholders.

Take a few minutes and think about that. Think about how you might be able to get creative with controls, dig deeper into detection, build better isolation for risky processes or even make entirely new architectures to contain risk ~ even as you enable business in new ways.

In the future, this had better be the way we think about working with and protecting businesses. If not, we could find ourselves on the sideline, well outside of the mainstream (if you aren’t there already in some orgs). 

Great work Aaron and thanks for the insights.

Welcome Red Dragon Rising

Posted on by
Reply

J0289893

Please join me in welcoming Red Dragon Rising to the fold. The Dragon team will be posting a variety of international threat intelligence information, cyber warfare research and engaging commentary. Stay tuned here for a new strain of content on the site, which will be meshed in with the traditional content we have been bringing you throughout the years. 

You can also find the Dragon team on Twitter @RedDragon1949.

As always, thanks for reading and let us know what you think of the new content and some of the intelligence we will be sharing.

OpUSA:: Feint or Fail?

Posted on by
5

So, yesterday was the date of the much awaited OpUSA, originally proclaimed to be a decisive attack on the US banking and government infrastructures. Thankfully, there seemed to be little impact on US banking or government, and while some commercial and even government sites did get attacked, the sustained impact seemed to be fairly well contained.

Below are a few thoughts on OpUSA and observations made from the data we saw around the Internet (in no particular order):

  • Anonymous groups seemed to be alluding to some infighting, with some groups mocking others and some fragments calling the entire operation a fake. There does seem to be some form of power struggle or competition going on inside the loose alignment of cells, at least from what conversations could be reviewed on Twitter, other social media and the paste bin releases.
  • Many of our team considered the possibility that OpUSA was a feint, designed to attract media attention and recruit new talent, even as primary groups and forces remained on the side lines. From a strategic point, this might make sense, though the in-fighting argument above seems more likely.
  • There seemed to be a large focus on attacking sites primarily powered by PHP. Certainly there are groups and cells inside the movement where their primary focus is PHP attacks and their exploits and tools are solely geared to PHP compromises. Other platforms are likely to remain in scope and within reach, but the majority of the attacks and compromises released yesterday seemed to revolve around PHP.
  • The 10,000 credit card release was MOSTLY a bust. All of the cards we saw were already expired. HOWEVER, it should be noted that SSNs, security questions and other PII was included in that release, so the impacts are broader than just credit card information.
  • Lots of released account credentials, software licenses and such also came out with associated tag lines during the operation. Additionally, many of the folks posting released data to the paste bins and on Twitter also usually release a good deal of pirated software, media and music from what we could tell. It is likely that some of the actors involved in the movement also participate in software and media piracy.
  • At least 3 credit unions were included in the released target lists. This was interesting, especially given the previous Anonymous stance that citizens should replace banks with credit unions. One has to wonder why these three particular CUs were targeted or if they were merely tokens. 

Other than the usual chatter and jeers, there seemed to be little unique about OpUSA and the efforts identified with the campaign. The media is picking up on some additional items here and there, but largely, the operation was seen as being a smaller or less successful campaign than previous attack sets.

Save the Date for CMHSecLunch – May 13th

Posted on by
4

It’s almost time for another CMHSecLunch! This month, the event is May 13th, 11:30a – 1pm at Easton Mall food court. As always, it is FREE and open to anyone interested in infosec and IT to attend. You can find out more, track the event and RSVP all one page by clicking here.

We hope to see you there! 

Ask The Security Experts: Public Facing Workstations

Posted on by
3

This time around, we have a question from a reader named John: “I work in a small financial institution and we have problems with physical access to our computers. Many of our workstations sit in semi-public areas and could easily be attacked with USB devices or physical access when a teller or customer service person leaves the customers alone with the machine at a desk or cubicle. What advice do the experts have to help counter these types of attacks?”

Bill Hagestad started the conversation:

Recommended Points for mitigating this digital & physical vulnerability;

1) Remove workstations from semi-public areas; 2) Deploy & install single – purpose Internet workstations at no more than 2 public locations with VERY limited access to financial institution records only after 3 factor authentication has been authorized by credentialed users only; 3) Set time limites on inactive sessions on all banking terminals to logoff after physical proximity to machine exceeds 15 seconds; 4) Enforce 32 random, alpha-numeric character password changes to all critical financial institutional systems weekly; and, 5) Implement and /or continue aggressive financial institution information assurance education program with goal of 100% employee participation; review/update monthly and, 6) Mandate information security and awareness program participation from financial institution leadership throughout all employees and ranks within the organization.

John Davis expanded: I know how difficult this is for financial institutions. Your customer service representatives need computers in their cubicles in order to provide service to your customers, while at the same time those same computers are a main point of physical vulnerabilitiy. Easy steps can be taken, though, to harden these work stations.

First, workstation users should be allotted local administration rights on their systems only when a business need is present. So, CSR workstations should have their USB and DVD ports disabled. Furthermore, their is no need for them to have the ability to upload or download software. In addition, workstations in publicly accessible areas must be turned off each and every time they are unattended. Perhaps you could implement a system similar to the cut off device used on treadmills or at casinos: CSRs would have to clip a device from their clothing to the workstation before it will work. You could accompany this with biometric access for quick and easy access for the users.

Jim Klun added:

From my experience, and assuming the worst case of Windows systems configured as normal workstations with end-users having admin level access, some immediate things I would do:

1. Disable all removable media access at the hardware ( i.e. BIOS) level. At minimum: disable ability to boot from such sources. or: remove all DVD and CDROM drives and physically disable USB ports. (e.g. glue) 2. Ensure all workstations log activity and ensure that the logs are directed to a central log repository and reviewed. Example: http://www.intersectalliance.com/projects/SnareWindows/ 3. Ensure surveillance cameras cover workstation areas. 4. Aggressive screen-lock settings 5. Removal of admin access for all but limited support staff if at all possible. 6. Consider Usage of security cabinets for workstations: Example: http://www.globalindustrial.com/g/office/computer-furniture/cabinets/orbit-side-car-cabinet 7. Network Access Control to limit what devices are allowed on the local network. That unattended RJ45 jack or poorly secured wireless environment is as much a threat as that USB port or CDROM. Bluetooth setting should also be reviewed. 8. Ensure all sensitive information traveling over the local LAN is encrypted. 9. Use a firmware password ( e.g drivelock or a BIOS power-on password) to limit who can boot the machine. 10. Monthly re-iteration of security policies – including need to lock workstations. In my experience such messages are best tied to real-world examples. It makes the risk real – not just an abstract “security guy” worry. For example, this event could be used to ensure employees are aware that an unlocked workstation could lead to the installation of malware: http://news.techworld.com/security/3256513/sovereign-bank-and-penfed-warn-customers-after-keyloggers-are-found-on-laptops/

I note that both JD and Bill talk about enhanced authentication – including the use of proximity devices. Using such devices ( mostly bluetooth ) to secure these workstations sounds like a great idea to me and may be the easiest and most effective solution. Once the financial institution walks away from the workstation – it’s locked and ideally will not boot. http://btprox.sourceforge.net/ – open source Google “computer proximity lock” for a number of commercial alternatives.

Adam Hostetler closed the conversation with:

Everyone has really good suggestions so far. I am a fan of the simple phsyical solutions. I would put the workstations in locked cages. This would prevent any malicious people from inserting USB devices or CDs, or implanting sniffers between the keyboard and USB ports. Additionally, follow the other advice of disabling them through software, just to be sure.

Another solution may be to move to a thin client solution. It is possible to buy thin clients that have no USB ports or optical drives. This would also ensure that no sensitive information was on the workstation, in the event that it was stolen.

April Touchdown Task

Posted on by
2

April’s touchdown task for the month is a suggestion to update your contact list that you should have included in your incident response policy.

A few minutes now to make sure the right people are in the list and that their contact information is current could pay off largely down the road. It might also be a good time to check to make sure your contact process has been updated to include SMS/texting, Skype and/or other supported technologies that may have not been around when your policy was last updated.

SDIM Project Update

Posted on by
2

Just a quick update on the Stolen Data Impact Model (SDIM) Project for today.

We are prepping to do the first beta unveiling of the project at the local ISSA chapter. It looks like that might be the June meeting, but we are still finalizing dates. Stay tuned for more on this one so you can get your first glimpse of the work as it is unveiled. We also submitted a talk at the ISSA International meeting for the year, later in the summer on the SDIM. We’ll let you know if we get accepted for presenting the project in Nashville.

The work is progressing. We have created several of the curve models now and are beginning to put them out to the beta group for review. This step continues for the next couple of weeks and we will be incorporating the feedback into the models and then releasing them publicly.

Work on phase 2 – that is the framework of questions designed to aid in the scoring of the impacts to generate the curve models has begun. This week, the proof of concept framework is being developed and then that will flow to the alpha group to build upon. Later, the same beta group will get to review and add commentary to the framework prior to its initial release to the public.

Generally speaking, the work on the project is going along as expected. We will have something to show you and a presentation to discuss the outcomes of the project shortly. Thanks to those who volunteered to work on the project and to review the framework. We appreciate your help, and thanks to those who have been asking about the project – your interest is what has kept us going and working on this problem.

As always, thanks for reading, and until next time – stay safe out there!