Login  |  Register  |  Contact
Wednesday, January 20, 2010

Incite 1/20/2010 - Thanks Mr. Internet

By Mike Rothman

Good Morning:

I love the Internet. In fact, I can’t imagine how I got anything done before it was there at all times to help. Two examples illustrate my point. On Monday, I went to lunch with the family at Fuddrucker’s, since they had off from school. They say a big poster of Elvis with a title “The King” underneath. They had heard of Elvis, but didn’t know much about him.

Mr. Internet kills the Maytag Man The Boss and I were debating how old Elvis was when he had that unfortunate toilet incident. I whipped out the iPhone, took a quick peek at Wikipedia, and learned the King died when he was 42. Oh crap, that’s not much older than I am right now. Then we went into his history and music and the kids actually learned something. Thanks, Mr. Internet.

Next up, I’ve been having some problems with my washing machine. So I check out the appliance boards on the Internet (thanks to the Google) and figure out what the error code means and a few ideas on how to fix it. Turns out it’s very likely a control unit issue. Amazingly enough, there is a guy in the Southeast who fixes the unit for half the price of buying a new part.

The guy sends me a little PDF on how to remove the control unit (it was a whopping 3 Torx screws and unplugging a bunch of wires). I put the unit in a box and sent it off. It could not have been easier. Thanks, Mr. Internet.

Now what would I have done 10 years ago? I would have called Sears. They would have come over, charged me for the service call ($140), replaced the control unit ($260), and I’d be good to go. $400 lighter in the wallet, of course.

They say an educated consumer is the best consumer. Not for the old Maytag Man, I guess. Don’t think he’s sending thanks to Mr. Internet.


Photo credit: “Maytag Man Inflatable” originally uploaded by arbyreed

Incite 4 U

This week we got contributions from almost everyone, which has always been my evil plan. And as much as I like the help, I do think having a number of opinions weighing in makes things a lot better – for everyone.

  1. China wastes a zero day on IE6? – It seems that the zero day vulnerability exploited by China doesn’t only work on Internet Explorer 6, but according to this article in Dark Reading may also work on IE 7 and 8, and might even work around the DEP (Data Execution Protection) feature of XP and Vista. Considering all the old vulnerabilities in IE6 (you know, something you should have dumped years ago), you have to wonder if the attackers just assumed we weren’t dumb enough to still use ancient code open to old exploits. Without listing all the permutations, it looks like IE8 on Vista or Windows 7 (because of that ASLR anti-exploitation thingy) may be secure, but everything else is exploitable and Microsoft is issuing an emergency patch. I realize it’s painful to think you might have to actually update that 10 year old enterprise application so it works with a browser released after 2001, but it’s time to suck it up and browse like it’s 2010. – RM

  2. They are better than us – Clever programmers working on a single project, test their code against live servers, monitor effectiveness, and evolve the code to get better every day. Working with operating systems I used to see this dedication. Some of the programming teams I worked on bordered on fanaticism and worked hard to become better programmers. Teams were like coder’s guilds, where more experienced members would review, teach, and occasionally shred other members for shoddy work. They worked late into the night, building new libraries of code, and studied their craft every night on the train ride home. They knew minutiae about protocols and compilers. I swear a couple of them thought in hexadecimal! When I read blogs like “An Insight into the Aurora Communications Protocol” I get the picture that the hackers are more professional than the “good guys” are. Hackers use obfuscation, SSL variations, code injection, command and control networks, and stolen source code to create custom 0-days. These highly motivated people have rapidly evolving skills. What worries me about Aurora isn’t the sophistication of the attack, but the disparity in dedication between attacker and your typical corporate developer. One side lives this stuff and one has a job. This is getting worse before it gets better. – AL

  3. Here’s a serving of humble pie. Eat it! – The truth of the matter is that a lot of security folks fail. Almost as often as marketing folks. Combine the two and you get…me. It does make sense to do a little soul searching and this post from Dan Lohrmann on CSOOnline really resonated. Basically his contention is that security folks come across as unusually proud or overconfident. That’s politically correct. I’d say in general we’re a bunch of arrogant asses. Not everyone, but more than a few. The reality is security folks need a bit of an edge, but at the end of the day we still need to be respectful to our customers. Yes, those idiots who get pwned all the time are our customers. So think about that next time you want to throw some snark in their direction. Just share it on Twitter. Like me. – MR

  4. Things in public, are, you know, public – On The Network Security Podcast last night we talked a bit about this article by James Urquhart over at CNet on the Fourth Amendment in the cloud. Actually, forget about the fourth amendment (that’s the search and seizure one for you engineering majors), when it comes to the Internet and privacy repeat after me – “if it’s on the Internet, it isn’t private, and never goes away”. The article emphasizes that anything you store on Internet services (I’m not limiting this to cloud) that is accessible by your service provider can’t be considered private under current law. Phone and paper mail are protected, but the law hasn’t been expanded beyond that. But with all the hacks of services going on, I think it’s safer to assume everything might someday become public anyway. As someone who once had some private Twitter direct messages exposed thanks to someone else with a weak password, trust me on this one. – RM

  5. Business Relevance by Balanced Scorecard? – We continue to struggle with business relevance, every day. And I’m certainly not too proud to borrow a good idea from someone else if it can get me where I need to go. So seeing this post on selling security with the balanced scorecard got me thinking. Can a well-worn general business concept be useful to us security hacks? The verdict is… maybe. I’m hedging because it depends on your culture. So whether it’s relevant to try to quantify the “learning and growth” aspect or not, the point is to try to understand and communicate business relevance. – MR

  6. Blind as a bat – I’m not a big fan of surveys. You know that. But like everything else, some data can be used as a tool to make a point that needs to be made. So my pals over at EMA did a survey and it showed that only 19% of some group is adequately monitoring their systems. Yeah, that’s a problem. No data. No early warning system. No forensics. No nothing. Richard Bejtlich made a point on Twitter today that 2010 will be the year when intrusions became a hotter topic than compliance. I expect incident detection and response to be big. Not if we don’t have any data. So think about your data collection efforts and whether you have enough data to find that needle in a haystack. – MR

  7. You’ve got to earn that ‘trust’…SQL Server 2008 R2 is scheduled for release in May of this year. I am looking forward to getting my hands on a copy to test out transparent database encryption and see exactly what data is pushed into the audit log, or if we are just going to get the same old syslog garbage. Given the number of new interfaces and amount of collaboration software being added, I am a little nervous about platform security. Which raises the question: does any software company get to advertise any new product as “A trusted and scalable platform”? The old platform maybe. I give Microsoft the benefit of the doubt nowadays when it comes to security, as they have made huge strides and have done some very smart things with their SDLC, but every database vendor for every major release has seen a big spike in vulnerabilities in the first few months of deployment. With several new interfaces and data sharing applications like Excel and PowerPivot connecting to the database, I think I’ll wait a little while before I trust it. – AL

  8. That’s a not a hack, it’s a feature… – I’m a MiFi user, as is Rich and probably a lot of you. When you work remotely, having constant 3G connectivity is critical. I’ve been frustrated with the MiFi WiFi (say that 10 times fast), so I’ve basically been using the MiFi in USB mode. Good thing, since a “feature” in the configuration interface makes the MiFi easy to hack. Of course, it was a great idea to build in CGI parameters to read and change MiFi settings. Threat model, anyone? A hacker can change network settings, which I think some folks have proven is a bad thing (DNS, right?). They will patch it and the impact will be minimal, but it does bring up yet another issue with consumerization of technology. Some of your employees have these devices and they are connecting into your network. So yes, you need to train the users about how to use this stuff responsibility. Good times. – MR

—Mike Rothman

Tuesday, January 19, 2010

Project Quant: Database Security - Monitoring

By Adrian Lane

First some project housekeeping: We have now completed the Secure phase of Project Quant for Database Security: Patch, Configure, Restrict Access, and Shield. Here are the links for the Introduction, Process Framework, Planning Part 1, Planning Part 2, and all four phases of Discovery. Next we move into the monitoring phase, where we first cover database activity monitoring.

Database monitoring is distinctly different from auditing: it provides near-real-time detection, heterogeneous database support, aggregation and correlation, and secure event storage; it also offers more forms of event collection than audit and transaction log files. Securosis has our own definition of database activity monitoring. Databases do not have monitoring built in, rather this function is provided through other products, typically from third parties.

The two primary use cases are security and compliance. The policies to support each will be different, and each option will favor different methods of data collection and warrant integration with different applications used by different stakeholders in the security process. The first step is to identify your goals and outline how the product is to be used. Later you will move on to the selection of a product, development of policies to be enforced, and finall deployment and integration. In this phase we are only covering the monitoring of systems and alert generation, but we will cover blocking and protection in a future post.


  • Time to identify databases to protect.
  • Time to identify security goals and compliance requirements.
  • Time to identify stakeholders. These are the people or departments who receive the reports and decide how to act on them.
  • Time to outline process and workflow. Specify how you want the product to work, how it is to be managed, and which systems you wish to integrate with.

Develop Policies

  • Variable: Cost to identify and acquire monitoring solution. Assuming a monitoring solution is not in place, the time it takes to evaluate one or more products and the cost of purchasing.
  • Time to identify data collection requirements. Depending upon goals, select an appropriate data collection method.
  • Time to create rules and polices.
  • Time to specify response and incident handling. Each policy will generate information or an alert if a policy violation is detected.
  • Time to create report templates. Templates will be used to present summary and detailed findings to stakeholders.


  • Time to deploy tool.
  • Time to deploy policies.
  • Time to test controls.
  • Time to integrate with existing systems.


  • Time to document.
  • Variable: Review suitability of controls.

—Adrian Lane

FireStarter: Security Endangered Species List

By Mike Rothman

Our weekly research meeting started with an optimistic plea from yours truly. Will 2010 finally be the year the signature dies? I mean, come on now, we all know endpoint AV using only signatures is an accident waiting to happen. And everywhere else signatures are used (predominantly IPS & anti-spam) those technologies are heavily supplemented with additional behavioral and heuristic techniques to improve detection.

But the team thought that idea was too restrictive, and largely irrelevant because regardless of the technology used, the vendors adapt their products to keep up with the attacks. Yes, that was my idea of biting sarcasm.

We broadened our thinking significantly, to think about why we haven’t been able to really kill off any security technology, ever. How many of you still use token authenticators? Or line encryptors? It seems once we implement something, we get to live with it for 20 years.

Have you ever tried to actually kill a technology? Someone always finds an edge case where you’d be dead if it happens, so you can’t pull the trigger. Who cares that you have a higher likelihood of getting hit by a meteor in the cranium? Not sure about you, but that annoys the crap out of me.

With all the time and money we spend maintaining and paying for these tools, we aren’t doing more strategic things for the business. Our world is complex enough. We need to make it a point this year to get rid of some of these long-in-the-tooth technologies.

So for this week’s thought generator, let’s put together a security “endangered species list” of things we want to kill. I’ll start:

Signature-based AV Engines – Come on, man! We keep these fat and dumb AV engines around because we are worried that the Melissa virus will make a comeback. Now the vendors need a frackin’ cloud to keep track of all the signatures, which don’t work anyway – given that most of the bad guys use AV*Test.org to make sure the major engines are blind to their stuff.

As an alternative, we can (and should) be moving towards a whitelist based approach on servers, where you can lock down the applications, since your servers don’t get pissed when they can’t run Tiger Woods golf or watch March Madness online. These tools are ready for prime time now, and it’s time we killed off the old and busted way of doing things.

And you shouldn’t need to keep paying your desktop AV vendor to maintain that signature database, especially since most of them already offer white-list technology as a different product.

On the endpoints, do we think these AV engines are actually doing any good? Aren’t we better off focusing on patching and ensuring some of the anti-exploitation technologies (like DEP and ASLR) are used within the applications you let users run on their devices? Then we also have to make sure we are watching more closely for compromised endpoints, so bust out that network monitor and ensure you have egress filtering in use. I described these techniques in Low Hanging Fruit: Network Security last week.

With the increasing consumerization of IT, assuming you have control of the endpoint is probably naive at best. Imagine what good all the AV researchers could do if they weren’t spending all day auto-generating signatures?

OK, that one was a bit easy and predictable. As Rich would say, what’s different about that? Nothing, I just wanted to get rolling.

HIPS – As I continue my attack on everything signature, why does HIPS (Host Intrusion Prevention) still exist? I get that folks don’t really do HIPS on the endpoint, but far too many still kill the performance of their servers by comparing activity to known attack code. I’m sure there are some use cases where HIPS is useful, but is it worth the performance penalty and the cost of management and maintenance? Yeah, probably not.

Repeat after me: Black lists are for the birds. Black lists are for the birds. So why do we care about HIPS anymore? Should this also be on the list of security technologies to die?

What say you? Tell me why I’m wrong. What’s on your list? Put it in the comments, and be sure to mention:

  • The technology
  • Why it needs to go
  • What compensating controls can be used for at least equal protection

Remember the best comment of the week can feel good about making a donation to a worthy charity.

Let’s all sing now: The Roof, the roof, the roof is on fire… Now discuss!

—Mike Rothman


By David J. Meier

We’ve all heard the stories: employee gets upset, says something about their boss online, boss sees it, and BAM, fired. As information continues to stick around, people find it increasingly beneficial to think before launching a raging tweet. Here lies the opportunity: what if I can pay someone to gather that information and potentially get rid of it? Enter ReputationDefender.

Their business consists of three key ideas:

  • Search: Through search ReputationDefender will find and present information about you so it’s easy to understand.
  • Destroy: Remove (for a per-incident fee) information that you don’t care to have strewn about the Internet.
  • Control: Through search and destroy you can now control how others see you online.

The company currently has multiple products that all play to specific areas of uncertainty most people have online: children, reputation, and privacy. Reputation is broken out into two different products, where one side takes on unwanted information, and the other appears to be SEO for your name (let’s not go there). The two main questions you may be asking yourself about the service are whether it works and, conversely, whether it’s worthwhile?

ReputationDefender’s approach makes sense, but isn’t practical in terms of execution. If there was a service today that could reliably remove information that might be incriminating or defamatory in nature from all the dark corners of the Internet, the game of privacy would be considerably different. Truth be told, that’s not how it works. While this is a topic that we could discuss at great lengths the simple take away is information replicates and redistributes at an exponential rate which adds to the depth and complexity of information sprawl. Now take into consideration all the sites that go to great lengths to keep information free from manual expungement: Wikileaks, The Pirate Bay, and The Onion to name a few. OK, well, not The Onion, but that’s still some funny stuff. The point is that if someone wants to drag your otherwise good reputation through the mud, there are far too many ways to publish it with relatively little you can do about it. Paying someone $44.90 (minimum price to enroll in a monthly MyReputation subscription plus use the ‘Destroy’ assistance one time) isn’t going to change that. Not convinced? Keep an eye out for the way law enforcement is scouring the Internet these days, using it as a preemptive tool to address what some may consider an idle threat, and you can start to see that there’s more archiving done than you’d probably care to think about.

Take a realistic approach to the root of the problem by saying that anything you post to the Internet will never be guaranteed private forever. Sites are bought out, information is sold, and breaches / leaks are a daily occurrence. The only control you have is how you put that information out in the first place. I wish it were different, but for $14.95 a month (sans any ‘Destroy’ attempts) you are better off investing in encryption or password management software to reduce your exposure where you do have some control. Then again, Dr. Phil may be able to persuade you otherwise.

P.S. I’m confident this service is full of holes, but you might say I don’t have any real proof. That’s going to change though as we put the service to the grinder on Mike and Rich. Stay tuned!

—David J. Meier

Monday, January 18, 2010

Quant for Databases: Open Question to Database Security Community

By Adrian Lane

Should we cover code and query analysis?

We have an open question about how much coverage, if any, we should provide to embedded application code or query analysis for the purpose of database security. We are on the fence about including SQL Injection prevention (application code changes or use of stored procedures). Obviously code injection remains a major issue for most applications, especially web facing applications as new threats are discovered on a regular basis. SQL Injection attacks are directed at the database, but typically addressed at the application layer or supporting services. It is, however, a capability within the database to thwart SQL Injection through parameter screening and data type matching capabilities provided with stored procedures. For most firms this is handled in the realm of application security.

As such, we would like to defer the question to the community at large: Should we cover query analysis and code injection prevention and develop a process for code verification ad part of this Quant project? Where does this responsibility lay within your organization today? Is it purely part of the application security teams job, or does it fall upon DBA’s and database security team?

Please send in your thoughts.

—Adrian Lane

Project Quant: Database Security - Shield

By Adrian Lane

Threats against databases and the information stored therein are not always conventional – SQL injection and buffer overflow attacks are two of the more common examples. There will be instances where patches for specific threats are unavailable, or security risks are simply inherent to the database features in use. Other exploits leverage weaknesses in database trust relationships, such as Oracle database links, DB2 remote command service, Sybase remote server access, or SQL Server trusted servers. Still others exploit flaws in the underlying network security, such as insecure communication or improperly implemented SSL connections. This task within the Secure phase of the Quant for Database Security project is intended to account for cases where the database is incapable of protecting itself without functional modification or “work arounds”.

We are advocating a “Patch and Shield” model to protect the database when patching comes up short. The approach might entail disabling database features, or further refinement to the database configuration. Virtual patching can also be accomplished through firewall, application firewall, or activity monitoring capabilities that block malicious requests. This process is not typically discussed in database vendor recommendations or “best practices”, as it directly addresses platform deficiencies and remediation through third party vendors, but is an important step for 0-day protection.

Identify Threats

  • Time to identify at-risk databases.
  • Time to review ingress/egress points and network protocols.
  • Time to identify threats and exploitable trust relationships.

Specify Countermeasures

  • Time to identify workarounds. For any given threat, there are normally multiple possible responses.
  • Time to specify communication protocol changes. Specify how you want to alter communications with the database, what filtering rules you wish to employ, etc.
  • Time to specify connectivity changes. Tune or remove services with implicit trust relationships, and verify existing listeners and network configurations are secure.
  • Time to develop regression test case.


  • Time to adjust database configuration.
  • Time to adjust firewall/IPS rules.
  • Time to install new security controls (e.g., new firewall, VPN, etc.).
  • Time to verify changes.


  • Time to document.

—Adrian Lane

Friday, January 15, 2010

Friday Summary: January 14, 2010

By Rich

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

Favorite Securosis Posts

Other Securosis Posts

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

Top News and Posts

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.


Thursday, January 14, 2010

Project Quant: Database Security - Restrict Access

By Adrian Lane

The next phase in our walk through database security is Restricting Access, through access control systems and permissions. Setting – or resetting as the case may be – database access control and account authorization is a major task. Most of the steps within this phase are self explanatory, but for databases with hundreds to thousands of users the amount of time spent on review will be significant. We need to check to see what is in place, compare that with documented polices, and return users and groups to their intended settings. Many users will have elevated permissions granted ‘temporarily’ to get a specific task done with data or database functions outside of their normal scope, or due to job function changes, but such permissions are often left in their ‘temporary’ state rather than being reset when no longer needed or appropriate. This form of “permissions creep” is a common problem. For permissions put in place to avoid breaking application functionality or required for certain users to perform temporary tasks, document the variance.

Review Access/Authentication

  • Time to collect existing users and access controls (unless collected in Review phase).
  • Time to identify authentication methods. Databases can use database, operating system, third party access control, and mixed modes of authentication. Check what is in place.
  • Time to determine approved authentication methods. Review prescribed authentication methods.

Determine Changes

  • Time to identify user permission discrepancies. Review user and administrative account permissions settings and note variances.
  • Time to identify group & role membership adjustments. Inspect roles and groups for members who should not be included. Review roles for unnecessary permissions or capabilities.
  • Time to identify password policies and settings. Check that password policies (strength, rotation, failed login attempts, lockout), and not variance to be addressed.
  • Time to identify dormant and obsolete accounts.


  • Time to alter authentication methods. Modify settings to meet with established guidelines.
  • Time to reconfigure and remove user accounts. Adjust permissions and remove capabilities.
  • Time to implement new roles and groups and adjust membership.
  • Time to reconfigure service accounts. Review application service accounts for authorization and group membership.


  • Time to document changes.
  • Time to document accepted variances from configuration.

In our next post we will move on to shielding the database.

—Adrian Lane

Management by Complaint

By Rich

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:

  1. Identify known rules you absolutely need to keep, e.g., outbound port 80, or an application’s access to its supporting database.
  2. Turn off everything else.
  3. Sit by the phone. Wait for the calls.
  4. 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.


Low Hanging Fruit: Network Security

By Mike Rothman

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:

  1. 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.
  2. 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

If you work for a company of scale, you have compromised machines. Do you know which ones? Monitoring your network traffic is certainly one way to figure out when something a bit non-kosher happens, but may not be an option for a quick fix.

But applying rules you have running on your firewalls and IPS devices to your outbound traffic leverages the stuff you already have. Yes, they don’t catch insider attacks or some weird encapsulated stuff, but what you find will surprise you (and the CIO). Ultimately, it’s about trying to figure out what’s broken, and this is a quick way to do it.

I’ll be digging into all these topics in more depth over the next few months, but I figure this will keep some of you busy for a little while. And if you already do all this stuff, it’s time for some more advanced kung fu. In the meantime, enjoy a cup of Joe – Rich is buying.

—Mike Rothman

Wednesday, January 13, 2010

Pragmatic Data Security- Introduction

By Rich

Over the past 7 years or so I’ve talked with thousands of IT professionals working on various types of data security projects. If I were forced to pull out one single thread from all those discussions it would have to be the sheer intimidating potential of many of these projects. While there are plenty of self-constrained projects, in many cases the security folks are tasked with implementing technologies or changes that involve monitoring or managing on a pretty broad scale. That’s just the nature of data security – unless the information you’re trying to protect is already in isolated use, you have to cast a pretty wide net.

But a parallel thread in these conversations is how successful and impactful well-defined data security projects can be. And usually these are the projects that start small, and grow over time.

Way back when I started the blog (long before Securosis was a company) I did a series on the Information-Centric Security Cycle (linked from the Research Library). It was my first attempt to pull the different threads of data security together into a comprehensive picture, and I think it still stands up pretty well.

But as great as my inspired work of data-security genius is (*snicker*), it’s not overly useful when you have to actually go out and protect, you know, stuff. It shows the potential options for protecting data, but doesn’t provide any guidance on how to pull it off.

Since I hate when analysts provide lofty frameworks that don’t help you get your job done, it’s time to get a little more pragmatic and provide specific guidance on implementing data security. This Pragmatic Data Security series will walk through a structured and realistic process for protecting your information, based on hundreds of conversations with security professionals working on data security projects.

Before starting, there’s a bit of good news and bad news:

  1. Good news: there are a lot of things you can do without spending much money.
  2. Bad news: to do this well, you’re going to have to buy the right tools. We buy firewalls because our routers aren’t firewalls, and while there are a few free options, there’s no free lunch.

I wish I could tell you none of this will cost anything and it won’t impose any additional effort on your already strained resources, but that isn’t the way the world works.

The concept of Pragmatic Data Security is that we start securing a single, well-defined data type, within a constrained scope. We then grow the scope until we reach our coverage objectives, before moving on to additional data types. Trying to protect, or even find, all of your sensitive information at once is just as unrealistic as thinking you can secure even one type of data everywhere it might be in your organization.

As with any pragmatic approach, we follow some simple principles:

  • Keep it simple. Stick to the basics.
  • Keep it practical. Don’t try to start processes and programs that are unrealistic due to resources, scope, or political considerations.
  • Go for the quick wins. Some techniques aren’t perfect or ideal, but wipe out a huge chunk of the problem.
  • Start small.
  • Grow iteratively. Once something works, expand it in a controlled manner.
  • Document everything. Makes life easier come audit time.

I don’t mean to over-simplify the problem. There’s a lot we need to put in place to protect our information, and many of you are starting from scratch with limited resources. But over the rest of this series we’ll show you the process, and highlight the most effective techniques we’ve seen.

Tomorrow we’ll start with the Pragmatic Data Security Cycle, which forms the basis of our process.


Yes Virginia, China Is Spying and Stealing Our Stuff

By Rich

Guess what, folks – not only is industrial espionage rampant, but sometimes it’s supported by nation-states. Just ask Boeing about Airbus and France, or New Zealand about French operatives sinking a Greenpeace ship (and killing a few people in the process) on NZ territory.

We’ve been hearing a lot lately about China, as highlighted by this Slashdot post that compiles a few different articles. No, Google isn’t threatening to pull out of China because they suddenly care more about human rights, it’s because it sounds like China might have managed to snag some sensitive Google goodies in their recent attacks.

Here’s the deal. For a couple years now we’ve been hearing credible reports of targeted, highly-sophisticated cyberattacks against major corporations. Many of these attacks seem to trace back to China, but thanks to the anonymity of the Internet no one wants to point fingers.

I’m moving into risky territory here because although I’ve had a reasonable number of very off the record conversations with security pros whose organizations have been hit – probably by China – I don’t have any statistical evidence or even any public cases I can talk about. I generally hate when someone makes bold claims like I am in this post without providing the evidence, but this strikes at the core of the problem:

  1. Nearly no organizations are willing to reveal publicly that they’ve been compromised.
  2. There is no one behind the scenes collecting statistical evidence that could be presented in public.
  3. Even privately, almost no one is sharing information on these attacks.
  4. A large number of possible targets don’t even have appropriate monitoring in place to detect these attacks.
  5. Thanks to the anonymity of the Internet, it’s nearly impossible to prove these are direct government actions (if they are).

We are between a rock and a hard place. There is a massive amount of anecdotal evidence and rumors, but nothing hard anyone can point to. I don’t think even the government has a full picture of what’s going on. It’s like WMD in Iraq – just because we all think something is true, without the intelligence and evidence we can still be very wrong.

But I’ll take the risk and put a stake in the ground for two reasons:

  1. Enough of the stories I’ve heard are first-person, not anecdotal. The company was hacked, intellectual property was stolen, and the IP addresses traced back to China.
  2. The actions are consistent with other policies of the Chinese government and how they operate internationally. In their minds, they’d be foolish to not take advantage of the situation.
  3. All nation-states spy, includig on private businesses. China just appears to be both better and more brazen about it.

I don’t fault even China for pushing the limits of international convention. They always push until there are consequences, and right now the world is letting them operate with impunity. As much as that violates my personal ethics, I’d be an idiot to project those onto someone else – never mind an entire country.

So there it is. If you have something they want, China will break in and take it if they can. If you operate in China, they will appropriate your intellectual property (there’s no doubt on this one, ask anyone who has done business over there).

The problem won’t go away until there are consequences. Which there probably won’t be, since every other economy wants a piece of China, and they own too much of our (U.S.) debt to really piss them off.

If we aren’t going to respond politically or economically, perhaps it’s time to start hacking them back. Until we give them a reason to stop, they won’t. Why should they?


Incite 1/13/2010: Taking the Long View

By Mike Rothman

Good Morning:

Now that I’m two months removed from my [last] corporate job, I have some perspective on the ‘quarterly’ mindset. Yes, the pressure to deliver financial results on an arbitrary quarterly basis, which guides how most companies run operations. Notwithstanding your customer’s problems don’t conveniently end on the last day of March, June, September or December – those are the days when stuff is supposed to happen.

I can go for miles and miles and miles and miles and miles and miles. Oh yeah. It’s all become a game. Users wait until two days before the end of the Q, so they can squeeze the vendor and get the pricing they should have gotten all along. The sales VP makes the reps call each deal that may close about 100 times over the last two days, just to make sure the paperwork gets signed. It’s all pretty stupid, if you ask me.

We need to take a longer view of everything. One of the nice things about working for a private, self-funded company is that we don’t have arbitrary time pressures that force us to sell something on some specific day. As Rich, Adrian, and I planned what Securosis was going to become, we did it not to drive revenue next quarter but to build something that will matter 5 years down the line.

To be clear, that doesn’t mean we aren’t focused on short term revenues. Crap, we all have to eat and have families to support. It just means we aren’t sacrificing long term imperatives to drive short term results.

Think about the way you do things. About the way you structure your projects. Are you taking a long view? Or do you meander from short term project to project and go from fighting one fire to the next, never seeming to get anywhere?

We as an industry have stagnated for a while. It does seem like Groundhog Day, every day. This attack. That attack. This breach. That breach. Day in and day out. In order to break the cycle, take the long view. Figure out where you really need to go. And break that up into shorter term projects, each getting you closer to your goal.

Most importantly, be accountable. Though we take a long view on things, we hold each other accountable during our weekly staff meetings. Each week, we all talk about what we got done, what we didn’t, and what we’ll do next week. And we will have off-site strategy sessions at least twice a year, where we’ll make sure to align the short term activities with those long term imperatives.

This approach works for us. You need to figure out what works for you. Have a great day.


Photo credit: “Coll de la Taixeta” originally uploaded by Aitor Escauriaza

Incite 4 U

This week we got contributions from the full timers (Rich, Adrian and Mike), so we are easing into the cycle. The Contributors are on the hook from here on, so it won’t just be Mike’s Incite – it’s everybody’s.

  1. Who’s Evil Now? – The big news last night was not just that Google and Adobe had successful attacks, but that the Google was actually revisiting their China policy. It seems they just can’t stand aiding and abetting censorship anymore, especially when your “partner” can haz your cookies. The optimist in me (yes, it’s small and eroding) says this is great news and good for Google for stepping up. The cynic in me (99.99995% of the rest) wonders when the other shoe will drop. Perhaps they aren’t making money there. Maybe there are other impediments to the business, which makes pulling out a better business decision. Sure, they “aren’t evil” (laugh), but there is usually an economic motive to everything done at the Googleplex. I don’t expect this is any different, though it’s not clear what that motive is quite yet. – MR

  2. Manage DLP by complaint – We shouldn’t be surprised that DLP continues to draw comparisons to IDS. Both are monitoring technologies, both rely heavily on signatures, and both scare the bejeezus out of anyone worried about being overwhelmed with false positives. Just as big PKI burned anyone later playing in identity management, IDS has done more harm to the DLP reputation than any vendor lies or bad deployments. Randy George over at InformationWeek (does every publication have to intercap these days?) covers some of the manpower concerns around DLP in The Dark Side of Data Loss Prevention. Richard Bejtlich follows up with a post where he suggests one option to shortcut dealing with alerts is to enable blocking mode, then manage by user complaint. If nothing else, that will help you figure out which bits are more important than other bits. You want to be careful, but I recommend this exact strategy (in certain scenarios) in my Pragmatic Data Security presentation. Just make sure you have a lot of open phone lines. – RM

  3. USB CrytpoFAIL – As reported by SC Magazine, a flaw was discovered in the cryptographic implementation used by Kingston, SanDisk, and Verbatim USB thumbdrive access applications. The subtleties of cryptographic implementation escape even the best coders who have not studied the various attacks and how to subvert a cryptographic system. This goes to show that even a group of trained professionals who oversee each other’s work can still mess up. The good news is that this simple software error can be corrected with a patch download. Further, I hope this does not discourage people from choosing encrypted flash drives over standard ones. The incremental cost is well worth the security and data privacy they provide. If you don’t own at least one encrypted flash memory stick, I strongly urge you to get one for keeping copies of personal information! – AL

  4. I smell something cooking – Two deals were announced yesterday, and amazingly enough neither involved Gartner buying a mid-tier research firm. First Trustwave bought BitArmor and added full disk encryption to their mix of services, software, and any of the other stuff they bought from the bargain bin last year. Those folks are the Filene’s Basement of security. The question is whether they can integrate all that technology into something useful for customers, or whether it’s just 10 pounds of shit in a 2 pound bag. You also need to hand it to Symantec’s BD folks, who managed to buy a company no one has ever heard of – Gideon Technologies. Evidently they do something with SCAP and presumably it will work with their BindView stuff. I can safely assume both of these deals were at fire sale prices – where are my damn marshmallows? – MR

  5. Heartland pays, Visa wins again – You just gotta love a business model where you build an insecure payment network and then manage to transfer all risks back to your customers, while continuing to skim a non-trivial percentage off the top of pretty much the entire global financial system. I appreciate how the card brands (and their wholly-owned subsidy, the PCI council) continue to tell us that chip and PIN or other more-secure payment technologies are off the table due to the costs, while making everyone else spend silly money complying with PCI. Then, when a company that passes their assessment is later breached, they’re told they aren’t really compliant, and it’s time to pay up the incident response costs. I’ve been told Heartland Payment Systems is far from the poster child for even adequate security, and their total bill from Visa is now a $60M settlement (including existing fines already paid). Never forget, at Visa the house always wins. – RM

  6. Security and Developers Disconnect – Ben Tomhave’s post over on Falcon’s View about The Three Domains of Application Security. These domains make sense to security professionals, but don’t map particularly well to the way application architects and application developers deal (or need to deal) with security. Most projects I have worked on differentiate between architecture, design, and implementation with software projects; because the goals and stakeholders are different. The process used (agile, agile with scrum, waterfall, spiral, repaid prototyping, etc.) affects security features and testing, as well as secure coding practices. Some organizations build security test cases at the module level and perform basic security verification with their nightly builds, while most defer to the QA organization for product testing. Who writes the test cases, what they cover and and what forms of testing (fuzzing, white vs. black box, anti-exploitation, etc.) are all over the map. Worth a read as these three buckets help conceptualize how to apply security to application development, but they bely the practical difficulties where the rubber meets the road. – AL

  7. Tailor your message to the audience – My curmudgeonly alter ego, Jack Daniel (with Kung Fu beard), made some interesting points in his post on communicating security to non-security folks. He’s absolutely right. Most folks aren’t stupid, but they aren’t interested in the nuances of a 0-day or the latest drop of BackTrack. So keep in mind the next time you speak to the dev team, or the network guys, or the DBA jockeys, or mahogany row: you need to make sure your language, your message, and your conclusions align with what the audience expects and can handle. Yes, it’s hard. Yes, it requires a lot more work. But it’s probably less work than remaining irrelevant. – MR

  8. For those looking for jobs – Thankfully it’s been a long time since I’ve had to look for a job. As much as we think the tech downturn may be “unofficially over” (according to Forrester anyway), it’s still hard out there for some folks. Yesterday, a note on one of the mailing lists I follow mentioned the fellow was out of work for a year and trying to figure out how to be more employable. I’d point him (and everyone else) to Mike Murray and Lee Kushner’s InfoSecLeaders site and specifically their career advice Tuesday posts. Yesterday’s was about getting an insulting offer, but there is a lot of great stuff on that blog. And Lee and Mike are great guys, so you can always approach them to answer your questions directly. – MR

—Mike Rothman

Tuesday, January 12, 2010

Revisiting Security Priorities

By Mike Rothman

Yesterday’s FireStarter was one of the two concepts we discussed during our research meeting last week. The other was to get folks to revisit their priorities, as we run headlong into 2010.

My general contention is that too many folks are focusing on advanced security techniques, while building on a weak or crumbling foundation: the network and endpoint security environment. With a little tuning, existing security investments can be bolstered and improved to eliminate a large portion of the low-hanging fruit that attackers target. What could be more pragmatic than using what you already have a bit better?

Of course, my esteemed colleagues pointed out that just because the echo chamber blathers about Adobe suckage and unsubstantiated Mac 0-days, that doesn’t mean the run of the mill security professional is worried about this stuff. They reminded me that most organizations don’t do the basics very well, and that not too many mid-sized organizations have implemented a SDL to build secure code.

And my colleagues are right. We refocused the idea on taking a step back and making sure you are focusing on the right stuff for your organization. This process starts with getting your mindset right, and then you need to make a brutally honest assessment of your project list.

Understand that every organization occupies a different place along the security program maturity scale. Some have the security foundation in place and can plan to focus on the upper layers of the stack this year – things like database and application security. Maybe you aren’t there, so you focus on simple blocking and tackling that pundits and blowhards (like me!) take for granted, like patch management and email/web filtering.

All will need to find dollars to fund projects by pulling the compliance card. Rich, Adrian, and I did an interview with George Hulme on that very topic.

Security programs are built and operated based on the requirements, culture, and tolerance for risk of their organizations. Yes, the core pieces of a program (understand what needs to be protected, plan how to protect it, protect it, and document what you protected) are going to be consistent. But beyond that, each organization must figure out what works for them.

That starts with revisiting your assumptions. What’s changing in your business this year? Bringing on new business partners, introducing new products, or maybe even looking at new ways to sell to customers? All these have an impact on what you need to protect. Also decide if your tactics need to be changed. Maybe you need to adopt a more Pragmatic approach or possibly become more of a guerilla security leader. I don’t know your answer – I can only remind you to ask the questions.

Tactically, if you do one thing this week, go back and revisit your basic network and endpoint security strategy. Later this week, I’ll post a hit list of low hanging fruit that can yield the biggest bang for the buck. Though I’m sure the snot nosed kid running your network and endpoint stuff has everything under control, it never hurts to be sure.

Just don’t coast through another year of the same old, same old because you are either too busy or too beaten down to change things.

—Mike Rothman

Monday, January 11, 2010

Mercenary Hackers

By Adrian Lane

Dino Dai Zovi (@DinoDaiZovi) posted the following tweets this Saturday:

Food for thought: What if <vendor> didn’t patch bugs that weren’t proven exploitable but paid big bug bounties for proven exploitable bugs?

and …

The strategy being that since every patch costs millions of dollars, they only fix the ones that can actually harm their customers.

I like the idea. In many ways I really do. Much like an open source project, the security community could examine vendor code for security flaws. It’s an incredibly progressive viewpoint, which has the potential to save companies the embarrassment of bad security, while simultaneously rewarding some of the best and brightest in the security trade for finding flaws. Bounties would reward creativity and hard work by paying flaw finders for their knowledge and expertise, but companies would only pay for real problems. We motivate sales people in a similar way, paying them extraordinarily well to do what it takes to get the job done, so why not security professionals?

Dino’s throwing an idea out there to see if it sticks. And why not? He is particularly talented at finding security bugs.

I agree with Dino in theory, but I don’t think his strategy will work for a number of reasons. If I were running a software company, why would I expect this to cost less than what I do today?

  • Companies don’t fix bugs until they are publicly exploited now, so what evidence do we have this would save costs?
  • The bounty itself would be an additional cost, admittedly with a PR benefit. We could speculate that potential losses would offset the cost of the bounties, but we have no method of predicting such losses.
  • Significant cost savings come from finding bugs early in the development cycle, rather than after the code has been released. For this scenario to work, the community would need to work in conjunction with coders to catch issues pre-release, complicating the development process and adding costs.
  • How do you define what is a worthwhile bug? What happens if I think it’s a feature and you think it’s a flaw? We see this all the time in the software industry, where customers are at odds with vendors over definitions of criticality, and there is no reason to think this would solve the problem.
  • This is likely to make hackers even more mercenary, as the vendors would be validating the financial motivation to disclose bugs to the highest bidder rather than the developers. This would drive up the bounties, and thus total cost for bugs.

A large segment of the security research community feels we cannot advance the state of security unless we can motivate the software purveyors to do something about their sloppy code. The most efficient way to deliver security is to avoid stupid programming mistakes in the application. The software industry’s response, for the most part, is issue avoidance and sticking with the status quo. They have many arguments, including the daunting scope of recognizing and fixing core issues, which developers often claim would make them uncompetitive in the marketplace. In a classic guerilla warfare response, when a handful of researchers disclose heinous security bugs to the community, they force very large companies to at least re-prioritize security issues, if not change their overall behavior.

We keep talking about the merits of ethical disclosures in the security community, but much less about how we got to this point. At heart it’s about the value of security. Software companies and application development houses want proof this is a worthwhile investment, and security groups feel the code is worthless if it can be totally compromised. Dino’s suggestion is aimed at fixing the willingness of firms to find and fix security bugs, with a focus on critical issues to help reduce their expense. But we have yet to get sufficient vendor buy-in to the value of security, because without solid evidence of value there is no catalyst for change.

—Adrian Lane