The key to improving a web security programme is having a comprehensive metrics programme in place – a system capable of performing ongoing measurement of the security posture of production systems, exactly where the proverbial rubber meets the road.
Doing so provides direct visibility into which areas of the software development lifecycle (SDLC) programme are doing well and which ones need improvement. Failure to measure and understand where an SDLC programme is deficient before taking action is a guaranteed way to waste time and money – both of which are always extremely limited.
Below is a step-by-step strategy for building a website security programme that yields results:
- Assign an individual or group that is accountable for website security
These individuals or groups may include the board of directors, executive management, security teams and software developers. They should be commissioned and authorised to establish a culturally consistent incentives programme that will help move the organisation in a positive direction with respect to security.
- Find your websites – all of them – and prioritise
Prioritisation can be based on business criticality, data sensitivity, revenue generation, traffic volume, number of users, or other criteria the organisation deems important. Knowing what systems need to be defended and what value they have to the organisation provides a barometer for an appropriate level of security investment.
- Measure your current security posture from an attacker’s perspective
This step is not just about identifying vulnerabilities; while that is a by product of the exercise, it is about understanding what classes of adversaries you need to defend against and what your current exposure to them is. Just finding vulnerabilities is not enough. Measure your security posture the same way a bad guy would before exploiting the system – fixing those vulnerabilities first is what is important.
- Trend and track the lifecycle of vulnerabilities
At a minimum, measure how many vulnerabilities are introduced per production code release, what vulnerability classes are most prevalent, the average number of days it takes to remediate them, and the overall remediation rate. The result provides a way to track the organisation’s progress over time, and serves as a guide for which of the SDLC-related activities are likely to make the most impact. Anything measured tends to improve.
- Fast detection and response
Historically, it has been prudent to operate under the assumption that all networks are compromised, or are at least hostile. This is the case especially since everyone is only one zero-day away from a break-in. Borrowing from that frame of reference, application security professionals are well advised to take a similar approach and focus on the impact of that assumption. Start by asking the question: “If my application is already vulnerable, what action(s) should I begin taking?” If an organisation is breached, the real damage happens when the adversary is in the system for days, weeks, or months. If an intruder can be successfully identified and kicked off the system within hours, the business impact of a breach can be substantially minimised.
Each application security programme must be tailored to their environments, taking into account everything from corporate culture to regulatory requirements.
One of the lessons learned from the research resulting in the WhiteHat 2013 Website Statics Report is that there are no “best practices” that can be widely applied without these considerations and result in a measurable impact. Elements of an application security programme that work for those in the retail industry, for example, will not work for the banking sector.
Gabriel Gumbs is director of solutions architecture at WhiteHat Security.