Research

During my first two weeks at Securosis, I’ve gotten soundly thrashed for being too “touchy-feely.” You know, talking about how you need to get your mindset right and set the right priorities for success in 2010. So I figure I’ll get down in the weeds a bit and highlight a couple of tactics that anyone can use to ensure their existing equipment is optimized. I’ve got a couple main patches in my coverage area, including network and endpoint security, as well as security management. So over the next few days I’ll highlight some quick things in each area. Let’s start with the network, since it’s really the foundation of everything, but don’t tell Rich and Adrian I said that – they spend more time in the upper layers of the stack. Also a little disclaimer in that some of these tactics may be politically unsavory, especially if you work in a large enterprise, so use some common sense before walking around with the meat cleaver. Prune your firewall Your firewall likely resembles my hair after about 6 weeks between haircuts: a bit unruly and you are likely to find things from 3-4 years ago. Right, the first thing you can do is go through your firewall rules and make sure they are: Authorized: You’ll probably find some really bizarre things if you look. Like the guy that needed some custom port in use for the poorly architected application. Or the port opened so the CFO can chat with his contacts in Thailand. Anyhow, make sure that every exception is legit and accounted for. Still needed: A bunch of your exceptions may be for applications or people no longer with the company. Amazingly enough, no one went back and cleaned them up. Do that. One of the best ways to figure out what rules are still important is to just turn them off. Yes, all of them. If someone doesn’t call in the next week, you can safely assume that rule wasn’t that important. It’s kind of like declaring firewall rule bankruptcy, but this one won’t stay on your record for 7 years. Once you’ve pruned the rules, make sure to test what’s left. It would be really bad to change the firewall and leave a hole big enough to drive a truck through. So whip out your trust vulnerability scanner, or better yet an automated pen testing tool, and try to bust it up. Consolidate (where possible) The more devices, the more opportunities you have to screw something up. So take a critical look at that topology picture and see if there are better ways to arrange things. It’s not like your perimeter gear is running full bore, so maybe you can look at other DMZ architectures to simplify things a bit, get rid of some of those boxes (or move them somewhere else), and make things less prone to error. And you may even save some money on maintenance, which you can spend on important things – like a cappuccino machine. Segregate (where possible) No, I’m not advising that we go back to a really distasteful time in our world, but talking about our understanding that some traffic just shouldn’t be mixed with others. If you worry about PCI, you already do some level of segregation because your credit card data must reside on a different network segment. But expand your view beyond just PCI, and get a feel for whether there are other groups that should be separate from the general purpose network. Maybe it’s your advanced research folks or the HR department or maybe your CXO (who has that nasty habit of watching movies at work). This may not be something you can get done right away because the network folks need to buy into it. But the technology is there, or it’s time to upgrade those switches from 1998. Hack yourself As mentioned above, when you change anything (especially on perimeter facing devices), it’s always a good idea to try to break the device to make sure you didn’t trigger the law of unintended consequences and open the red carpet to Eastern Europe. This idea of hacking yourself (which I use the fancy term “security assurance” for) is a critical part of your defenses. Yes, it’s time to go get an automated pen testing tool. Your vulnerability scanners are well and good. They tell you what is vulnerable. They don’t tell you want can be exploited. So tool around with Metasploit, play with Core or CANVAS, or do some brute force work. Whatever it is, just do it. The bad guys test your defenses every day – you need to know what they’re finding. Revisit change control Yeah, I know it’s not sexy. But you spend a large portion of your day making changes, patching things, and fulfilling work orders. You probably have other folks (just like you) who do the same thing. Day in and day out. If you aren’t careful, things can get a bit unwieldy with this guy opening up that port, and that guy turning off an IPS rule. If you’ve got more than one hand in your devices on any given day, you need a formal process. Think back to the last incident you had involving a network security device. Odds are high the last issue was triggered by a configuration problem caused by some kind of patch or upgrade process. If it can happen to the FAA, it can happen to you. But that’s pretty silly when you can make sure your admins know exactly what the process is to change something. So revisit the document that specifies who makes what changes when. Make sure everyone is on the same page. Make sure you have a plan to rollback when an upgrade goes awry. Yes, test the new board before you plug it into the production network. Yes, having the changes documented, the help desk aware, and the SWAT team on notice are also key to making sure you keep your job after you reset the system. Filter outbound traffic

In Mike’s post this morning on network security he made the outlandish suggestion that rather than trying to fix your firewall rules, you could just block everything and wait for the calls to figure out what really needs to be open. I made the exact same recommendation at the SANS data security event I was at earlier this week, albeit about blocking access to files with sensitive content. I call this “management by complaint”, and it’s a pretty darn effective tactic. Many times in security we’re called in to fix something after the fact, or in the position of trying to clean up something that’s gotten messy over time. Nothing wrong with that – my outbound firewall rules set on my Mac (Little Snitch) are loaded with stuff that’s built up since I set up this system – including many out of date permissions for stale applications. It can take a lot less time to turn everything off, then turn things back on as they are needed. For example, I once talked with a healthcare organization in the midst of a content discovery project. The slowest step was identifying the various owners of the data, then determining if it was needed. If it isn’t known to be part of a critical business process, they could just quarantine the data and leave a note (file) with a phone number. There are four steps: Identify known rules you absolutely need to keep, e.g., outbound port 80, or an application’s access to its supporting database. Turn off everything else. Sit by the phone. Wait for the calls. As requests come in, evaluate them and turn things back on. This only works if you have the right management support (otherwise, I hope you have a hell of a resume, ‘cause you won’t be there long). You also need the right granularity so this makes a difference. For example, one organization would create web filtering exemptions by completely disabling filtering for the users – rather than allowing what they needed. Think about it – this is exactly how we go about debugging (especially when hardware hacking). Turn everything off to reduce the noise, then turn things on one by one until you figure out what’s going on. Works way better than trying to follow all the wires while leaving all the functionality in place. Just make sure you have a lot of phone lines. And don’t duck up anything critical, even if you do have management approval. And for a big project, make sure someone is around off-hours for the first week or so… just in case. Share:

As I sit here writing this, scenes of utter devastation play on the television in the background. It’s hard to keep perspective in situations like this. Most of us are in our homes, with our families, with little we can do other than donate some money as we carry on with our lives. The scale of destruction is so massive that even those of us who have worked in disasters can barely comprehend its enormity. Possibly 45-55,000 dead, which is enough bodies to fill a small to medium sized college football stadium. 3 million homeless, and what may be one of the most complete destructions of a city in modern history. I’ve responded to some disasters as an emergency responder, including Katrina. But this dwarfs anything I’ve ever witnessed. I don’t think my team will deploy to Haiti, and every time I feel frustrated that I can’t help directly, I remind myself that this isn’t about me, and even that frustration is a kind of selfishness. I’m not going to draw any parallels to security. Nor will I run off on some tangent on perspective or priorities. You’re all adults, and you all know what’s going on. Go do what you can, and I for one have yet another reason to be thankful for what I have. This week, in addition to Hackers for Charity, we’re also going to donate to Partners in Health on behalf of our commenter. You should too. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on Database Discovery. Securosis takes over the Network Security Podcast. Rich, Mike, and Adrian interviewed by George Hulme of Information Week on Attaining Security in the name of compliance. Adrian’s article in Information Security Magazine on Basic Database Security: Step by Step. Rich’s series of Macworld articles on Mac security risks. Rich was a judge for the top 10 web hacking techniques of 2009. The judging gets harder every year. Pepper wrote a piece on scheduling Mac patching over at TidBITS. Favorite Securosis Posts Rich: Database Password Pen Testing. Mike: FireStarter: The Grand Unified Theory of Risk Management – Great discussion on how risk management needs to evolve to become relevant. Adrian: Rich’s post on Yes Virginia, China Is Spying and Stealing Our Stuff. Meier: Yes Virginia, China Is Spying and Stealing Our Stuff – Maybe we can combine the idea behind the Mercenary Hackers post with Rich’s idea to hack China back. Adobe would be all smiley emoticon for sure. Mort: Low hanging fruit in network security. Other Securosis Posts Management by Complaint. Pragmatic Data Security: Introduction. Incite 1/13/2010: Taking the Long View. Revisiting Security Priorities. Mercenary Hackers. Favorite Outside Posts Rich: I’m going to cheat and pick some of my own work. I don’t think I’ve seen anything like the Mac security reality check series I wrote for Macworld in a consumer publication before. It’s hopefully the kind of thing you can point your friends and family to when they want to know what they really need to worry about, and a lot of it isn’t Mac specific. I’m psyched my editors let me write it up like this. Mike: Shopping for security – Shrdlu gets to the heart of the matter that we may be buying tools for us, but there is leverage outside of the security team. We need to lose some of our inherent xenophobia. And yes, I’m finally able to use an SAT word in the Friday Summary. Adrian: On practical airline security. It’s weird that the Israelis perform a security measure that really works and the rest of the world does not, no? And until someone performs a cost analysis of what we do vs. what they do, I am not buying that argument. Mort: Why do security professionals fail?. Meier: Cloud Security is Infosec’s Underwear Bomber Moment – Gunnar brings it all together at the end by stating something most people still don’t get: “This is not something that will get resolved by three people sitting in a room… …it requires architecture, developers and others from outside infosec to resolve.” Pepper: Google Defaults to Encrypted Sessions for Gmail, by Glenn Fleishman at TidBITS. AFT! Project Quant Posts Project Quant: Database Security – Restrict Access. Project Quant: Database Security – Configure. Top News and Posts Dark Reading on the Google hack by China. A lot of good, important information in here. Another Week, Another GSM Cipher Bites the Dust. Adobe hack conducted via 0-day IE flaw. Do security pros need a little humble pie? Top 10 Reasons Your Security Program Sucks and Why You Can’t Do Anything About It. Amrit does it again – funny, snarky, and all too true Insurgent Attacks Follow Mathematical Pattern. I’m sorry but we blew up your laptop (welcome to Israel). I want to know a) why they thought the laptop was a danger, and b) why they thought the screen (rather than the hard disk) was the dangerous part. Blog Comment of the Week Remember, for every comment selected Securosis makes a $25 donation to Hackers for Charity. This week’s best comment comes from ‘Slavik’ in response to Adrian’s post on Database Password Pen Testing: Adrian, I believe that #3 is feasible and moreover easy to implement technically. The password algorithms for all major database vendors are known. Retrieving the hashes is simple enough (using a simple query). You don’t have to store the hashes anywhere (just in memory of the scanning process). With today’s capabilities (CUDA, FPGA, etc.) you can do tens of millions of password hashes per second to even mount brute-force attacks. The real problem is what do you do then? From my experience, even if you find weak passwords, it will be very hard for most organizations to change these passwords. Large deployments just do not have a good map of who connects to what and managers are afraid that changing a password will break something. Share: