On Wednesday 19th September, Paul van Woudenberg and Theo van Niekerk, the founders of ThinkSmart, gave a talk at Cape Town SPIN: Built in, not bolted on: web application security done right. View the slides on Slideshare.
Below are my brief notes from their talk.
Security Risks Today
- Open Web Application Security Project (OWASP) is a worldwide, free, open organization focused on improving the security of applications. Contains tools and documentation.
- Network / infrastructure problem mostly sovled.
- are following the money and targeting web apps;
- often target the basic stuff, but that can still have severe consequences.
- There’s a need for stronger strategic approach to security, and alignment of development and security teams.
- Strong application security is good civic hygiene (Philip Zimmerman of PGP) and is often required for legal / compliance reasons.
- Security spending still targets network / infrastructure, so is in the wrong place. This is due to force of habit, old standards, compliance, and the perceived difficulty of security.
Focus on the software
- We need to focus on the software, but it’s a very different problem.
- Software is like clay where the network / infrastructure is like lego.
- Software being malleable is great for devs, because feature creation is easy, but it also means that it’s easier to leave security vulnerabilities.
- Software developers are the most important security resource. Their performance is measured on speed and features, not security, so there’s low motivation to spend time on security.
- Appeal to dev’s conscience: ruggedsoftware.org
- Send them on training. This takes time out of dev schedule, though, and there’s often no time to apply the learning on their return.
- In SDLC requirements are key to success and to security.
- Security requirements must be part of the specification, so that devs can be measured on the security of apps.
- Better security requires a change in the organisation (executive buy-in, secure SDLC).
- Security feature design is important, but hard to get right.
What to do
- The problem is that it takes time, and that security vulnerabilities are a ticking time-bomb.
- There’s hope! Everything you need (information, tools, techniques, training, plan) is available, and you can make a big difference.
How do I start today?
- Put security requirements in the spec. Start with generic ones:
- appoint a champion
The next steps
- Thread security through each phase of your SDLC. OpenSAMM (Software Assurance Maturity Model) can help: open framework to help formulate and implement security strategy.
- Helps you make guidance docs that are: simple, well-defined, measurable.
- Starts with Governance, Construction, Verification, Deployment. Breaks those into three Security Practice areas, each with three levels.
- Reduce security design flaws: do risk analysis on business requirements
- Drivers for Security Requirements: business needs; risk analysis; regulatory demands.
- Avoid security bugs