Hey Everyone, did you hear- WebGoat is full of security holes. Way to go FullDisclosure, you really nailed that one, though you did miss severl dozen vulnerabilities in the software (it is almost like it was designed to be vulnerable…), for example little trivial things like command injection. Did you hear from the vendor to see if they have a timetable to fix the flaws?

~ Joshbw

It is a truism in the application security world (or really any security) that in order to have an effective Security Program you need executive buyoff and executive support. To many this means that you need executives to care about security, be willing to fund it, and be willing to stand behind their security personel. This is certainly true, but there is a precursor step that is necessary for many development organization to move to truly institute effective Application Security – they need to mature as a software organization and embrace process.

When most software organizations start out they often embrace a seat of the pants development style, something often mistaken this as agile development, which has three very simple steps – Have Idea, Code Idea, Market Idea. As they mature they might realize that they should decide if they can sell the idea before they try to code it, rather than figure that out after the fact, and they decide they need to bring in testers to verify that they actually did code the idea. As a dev org matures they get to a platue were they have developed some process, but it resides on either side of the developers- they actually do analysis of an idea to see if it is worth the development costs, and they do testing and customer acceptance verification to make sure that the idea was implemented in a way that will meet customer’s needs, but at the end of the day all they expect developers to do is write code and testers to make sure the code does what it is supposed to.

The problem is, that is an arrangement that will not consistently produce robust code- security wise or otherwise. Verifying functionality only finds average use case flaws, but does not verify proper behavior across all concievable uses, and simply writing code without discipline will produce unmaintainable, fragile, redundant code. It is in this state that organizations start to care about security, but they aren’t willing to make real commitments to the changes necessary to see it happen. At this point they need to decide whether or not they are willing to change their development and test culture, and this is a very difficult decision to make and enforce.

If the decision is not made, the organization will trap themselves into an entirely reactive model to security threats- Problems are found by vulnerability assessment or customer reporting and fixed- tribal knowledge is gained among some developers and there is a short term downtick in that specific type of vulnerability among those specific developers- long term the org hasn’t learned much, and the information is not sustained. Almost no prevention will occur. This is because a preventitive model would require changes to how the code is written and verified.

If the decision is made, then the development team needs process placed on them and accountability to following that process. They can’t just write code anymore- they need coding standards detailing how they can write code and they need to get used to writing documentation. Developers hate writing documentation, but it is one of the most important things they can do- with documentation they can fully think through how they will code a feature before they start doing so (we don’t start pouring foundation before we decide on the blueprints for a house after all) spotting shortcomings of a particular method before they have spent a couple of days implementing it and they will provide something were the design itself can be tested rather than just the implementation. On the topic of testing, the dev org needs to get in the habit of hiring testers who are very skilled at thinking in terms of finding problems, rather than testers who are little more than stupid users that can determine whether a feature either works or doesn’t. Skilled testers are worth as much as a skilled developers, as effectively finding technical problems is just as hard as effectively coding solutions (one of the best interview test questions I have ever heard was “What do you think of your cell phone?”- a true tester may describe a couple of things they like, but then proceed to talk about the myriad of things that they wish were done better. A true tester is someone who perpetually sees the flaws in something, no matter how good it is). The testers also need to be given a strong voice- they are the verification for the developers and if their voice is not strong, then they can’t serve their purpose.

Doing this will give the security team a framework to then build in security controls into the development process. They need an actual process in place, otherwise they have no foundation to build off of. An existing and well defined development process is an input into any effective secure development lifecylce, and an SDL is ultimately the path to a preventitive approach to security. The problem is that it is very hard to change a development culture and it requires commitment from the top. Developers hate process, and they are going to be very resistant to implementing it. Executives need to make it abundandly clear that conforming to the process is the developers’ job- it is what they will be paid to do, and if they don’t do it they will not be paid. This will make no friends among the developers. That is why it is the hardest decision that a maturing development organization can make.

Incidentally, the same thing is true for OSS as for proprietary, however it is even more difficult to implement and enforce in an open distributed development environment. The payoff for either software is much more than just security- the overall quality of the product will improve as a result and the code will be easier to maintain as their will be documentation to refer to and a level of code quality enforced.

~ Joshbw

Vipin and Nitin Kumar have apparently released a proof of concept for their Vbootkit 2.0 attack against Win7 based machines. I’ve talke about the attack previously, as it is incorrectly labeled a Windows 7 attack- it is an attack against insecure boot process that then compromises Windows 7. Anyway, their rationale is -

The Kumars are concerned that the attack approach against Windows 7 they have unearthed might be modified by skilled miscreants to develop remote attacks, hence the decision to give white hat security researchers a leg up in developing defences. They also want to make the case to Microsoft that it ought to make improved security features available across all versions of Windows 7, not just the higher-end versions.

Apparently taking issue with the fact that BitLocker is only available on Enterprise and Ultimate versions of Windows. I’m not a huge fan of the tiered versions of Windows, but then again I have an alumni account at the MS company store so I don’t really mind paying $50 for Ultimate. At the same time, I think it is a bit crazy to expect bitlocker to be available for all users- the support costs associated with that idea are pretty high. Regardless, all of that is ignoring that a technical control is not ideal for their attack vector.

What leads to their VBootkit 2.0 being run is physical access to the machine- the ultimate enabler is that they are actually at the hardware. Technical solutions are an inherently poor mitigation to a physical problem. Physical controls are much more appropriate. In data centers simply putting the machine in a sufficiently designed locking server cabinent has neutered this attack, since the attacker would need to first break into the cabinent. For desktop users having a good locking, tamper proof case, the boot sequence set to boot from hard disk first, a BIOS password to protect the boot sequence, and a motherboard that isn’t prone to fail into bios when the keyboard buffer is full will prevent all but the most determined attackers. Physical controls for physical problems, technological controls for technological problems, and so forth.

Most of us are techies and immediately look for some nifty code that solves a problem, but enterprise security is only partially a tech problem. Some times a pad lock is better security than a strong password.

~ Joshbw