Research

The other day it hit me: Process is not that important to secure code development. Waterfall? Doesn’t matter. Agile process? Secondary. They only frame the techniques that create success. Saying a process helps create secure code is like saying a cattle chute tames a wild Brahma bull. Guidelines, steps, and procedures do little to alter code security, only which code gets worked on. To motivate developers to improve security, try less carrot and more stick. Heck, process is not even a carrot – it’s more like those nylon dividers at the airport to keep polite people from pushing and shoving to the front of the line. No, if you want to developers to write secure code, use peer pressure. Peer pressure is the most effective technique we have for producing secure code. That’s it. Use it every chance to you get. It’s the right thing to do. Don’t believe me? You think pair coding is about cross training? Please. It’s about peer pressure. Co-workers will realize you suck at coding, and publicly ridicule you for failing to validate input variables. So you up your game and double-check what you are supposed to deliver. Quality assurance teams point out places in the code that you screwed up, and bug counts come up during your raise review. Peer pressure. No developer wants his or her API banned because hackers trampled over it like fans at a Who concert. If you have taken management classes, you have heard about the Hawthorne Effect, discovered through studies in the 1920s and ’30s. In attempts to increase factory worker output, they adjusted working conditions, specifically looking for optimal lighting that produced the highest productivity. What they found, however, was that productivity has nothing to do with the light level per se, but went up whenever the light level changed. It was a study, so supervisors paid attention when the light changed to monitor the results. When the workers knew they were being watched, their productivity went up. Peer pressure. Why do you think we have daily scrum meetings? We do it so you remember what you are supposed to be working on, and we do it in front of all your peers so you feel the shame of falling behind. That’s why we ask everyone in the room to participate. These little sessions are especially helpful at waking up those 20-something team members who were up all night partying with their ‘bros’, or drinking Guinness and watching Manchester United till the wee hours of the morning. You know who you are. We have ‘Sprints’ for the same reason universities have exams: to get you to do the coursework. It’s your opportunity to say, “Oh, S$^)#, I forgot to read those last 8 chapters,” and start cramming for the exam. Only at work you start cramming from the deadline. 30 day sprints just provide more opportunities to prod developers with the stick than, say, 180 day waterfall cycles. I think Kent Beck had it wrong when he said that unacknowledged fear is the root cause of all software project failures. I think fear of the wrong things causes project failures. We specify priorities so we understand the very minimum we are responsible for, and we work like crazy to get the basics done. Specify security as the primary requirement, verify people are doing their jobs, and you get results. External code review? Peer pressure. Quality assurance? Peer pressure. Automated build failures? Peer pressure. The Velocity concept? Peer pressure. Testers fuzzing your code? Still peer pressure. Sure, creating stories, checklists, milestones, and threat analysis set direction – but none of those is a driver. Process frame the techniques we use, and the techniques alter behavior. The techniques that promote peer pressure, manifesting itself through fear or pride, are the most effective drivers we have. Disagree? Tell me why. Share:

I’m starting to think I shouldn’t take vacations. Aside from the Symantec acquisition of PGP and GuardianEdge last week, someone went off and released the first open source DLP tool. It’s called OpenDLP, and version 0.1 is currently available over Google Code. People have asked me for a long time why there aren’t any FOSS DLP options out there, and it’s nice to finally see someone put in the non-trivial effort and release a tool. DLP isn’t easy to create, and Andrew Gavin deserves major credit for kicking off the project. First, let’s classify OpenDLP. It is an agent-based content discovery/data-at-rest tool. You install an agent on endpoints, which then scans local storage and sends results to a central management server. The agent is a C program, and the management server runs on Apache/MySQL. The tool supports regular expressions and scanning of plain text files. Benefits Free. You can customize the code. Communications are encrypted with SSL. Supports any version of Windows you are likely to run. Includes agent management, and the agent is designed to be non-intrusive. Supports full regular expressions for building policies. Limitations Scans stored data on endpoints only. Might be usable on Windows servers, but I would test very carefully first. Unable to scan non-plain-text or compressed files, including current versions of Office (the .XXXx XML formats). No advanced content analysis – regex only, which limits the types of content this will work for. Requires NetBIOS… which some environments ban. I have been told via email (not from a DLP vendor, for the record) that the code may be a bit messy… which I’d consider a security concern. Thus this is a narrow implementation of DLP – that’s not a criticism, just a definition. I don’t have a large enough environment to give this a real test, but considering that it is a 0.1 version I think we should give it a little breathing space to improve. The to-do list already includes adding .zip file support, for example. I think it’s safe to say that (assuming the project gathers support) we will see it improve over time. In summary, this is too soon to deploy in any production capacity, but definitely worth checking out and contributing to. I really hope the project succeeds and matures. Share:

I’m catching up on my reading, and finally got a chance to peruse the NetworkWorld DLP Review. Here’s why I think you need to toss this one straight into the hopper: It only includes McAfee and Sophos – other vendors declined to participate. The reviewers state the bulk of their review was focused on test driving the management interface. The review did not test accuracy. The review did not test performance. The review did not compare “like” products – even the McAfee and Sophos offerings are extremely different, and little effort was made to explain these differences and what they mean to real world deployments. In other words, this isn’t really a review and should not inform buying decisions. This is like trying to decide which toaster to buy based on someone else’s opinion of how pretty the knobs are. I’m not saying anything about the products themselves, and don’t read anything between lines that isn’t there. This is about NetworkWorld publishing a useless review that could mislead readers. Share:

Use Case #2: Improve Efficiency Turn back the clock about 5 months – you were finalizing your 2010 security spending, and then you got the news: budgets are going down again. At least they didn’t make you cut staff during the “right-sizing” at the end of 2008, eh? Of course, budget and resources be damned, you are still on the hook to secure the new applications, which will require some new security gadgets and generate more data. And we cannot afford to forget the audit deficiencies detailed in your friendly neighborhood assessor’s last findings. Yes, those have to be dealt with too, and sometime in the first quarter, because the audit is scheduled for early May. This may seem like an untenable situation, but it’s all too real. Security professionals now must continue looking for opportunities to improve efficiency and do more with less. As we look deeper into this scenario, there are a couple of inevitable situations we have got to deal with: Compliance requirements: Government and industry regulations force us to demonstrate compliance – requiring gathering log files, parsing unneeded events, and analyzing transactions into human-readable reports to prove you’re doing things right. IT and Security must help Audit determine which events are meaningful, so regulatory controls are based upon complete and accurate information, and internal and external audit teams define how this data is presented. Nothing gets shut down: No matter how hard we try, we cannot shut down old security devices that protect a small portion of the environment. Thus every new device and widget increases the total amount of resources required to keep the environment operational. Given the number of new attack vectors clamoring for new protection mechanisms, this problem is going to get worse, and may never get better. Cost center reality: Security is still an overhead function and as such, it’s expected to work as efficiently as possible. That means no matter what the demands, there will always be pressure to cut costs. So this use case is all about how SIEM/LM can improve efficiency of existing staff, allowing them to manage more devices which are detecting more attacks, all while reducing the time from detection to remediation. A tall order, sure, but let’s look at the capabilities we have to accomplish this: Data aggregation: Similar to our react faster use case, having access to more data means less time is wasted moving between systems (swivel chair management). This increases efficiency and should allow security analysts to support more devices. Dashboards: Since a picture is worth a thousand words, a well architected security dashboard has to be worth more than that. When trying to support an increasing number of systems, the ability to see what’s happening and gain context with an overview of the big picture is critical. Alerts: When your folks need to increase their efficiency, they don’t have a lot of time to waste chasing down false positives and investigating dead ends. So having the ability to fire alerts based on real events rather than gut feel will save everyone a lot of time. Forensic investigations: Once the problem is verified, it becomes about finding root cause as quickly as possible. The SIEM/LM solution can provide the context and information needed to dig into the attack and figure out the extent of the damage – it’s about working smarter, not harder. Automated policy implementation: Some SIEM/LM tools can build automated policies based on observed traffic. This baseline (assuming it represents normal and healthy traffic) enables the system to start looking for _not normal activity, which then may require investigation. This use case is really about doing more with what you already have, which has been demanded of security professionals for years. There have been no lack of tools and products to solve problems, but the resources and expertise to take best advantage of those capabilities can be elusive. Without a heavy dose of automation, and most importantly a significant investment to get the SIEM/LM system configured appropriately, there is no way we can keep up with the bad folks. Use Case #3: Compliance Automation You know the feeling you get when you look at your monthly calendar, and it shows an upcoming audit? Whatever you were planning to do goes out the window, as you spend countless hours assembling data, massaging it, putting it into fancy checklists and pie charts, and getting ready for the visit from the auditor. Some organizations have folks who just focus on documenting security controls, but that probably isn’t you. So you’ve got to take time from the more strategic or even generally operational tasks you’ve been working on to prepare for the audit. And it gets worse, since every regulation has its own vernacular and rule set – even though they are talking about the same sets of security controls. So there is little you can leverage from last month’s PCI audit to help prepare for next month’s HIPAA assessment. And don’t forget that compliance is not just about technology. There are underlying business processes in play that can put private data at risk, which have to be documented and substantiated as well. This requires more domain expertise than any one person or team possesses. The need to collaborate on a mixture of technical and non-technical tasks makes preparing for an audit that much harder and resource intensive. Also keep in mind the opportunity cost of getting ready for audits. For one, time spent in Excel and PowerPoint massaging data is time you aren’t working on protecting information or singing the praises of your security program. And managing huge data sets for multi-national organizations across potentially hundreds of sites requires ninja-level Microsoft Office skills. Drat, don’t have that. As if things weren’t hard enough, regulatory audits tend to be more subjective than objective, which means your auditor’s opinion will make the difference between the rubber stamp and a book of audit deficiencies that will keep your team busy for two years. So getting as detailed