Web Application security for CISO's - 6 things to consider

At edgescan we assess 1000's of systems globally across both the web site & application layers. 

We assess both pre-production and production environments deployed to data centres and the cloud alike.

From experience the job of a CISO involves much more than cybersecurity but the CISO is required to set strategic direction for many aspects of security and be an oracle of knowledge....

Many of my CISO friends and colleagues understand the need to security across the entire systems development and maintenance lifecycle and have a large list of areas to cover off and secure not to mention maintaining compliance...

• Measuring the security maturity Level, and building an integrated approach to maintain posture
• Balancing cost/budget and risk prioritization
• Consolidation of metrics and trends to make informed decisions
• Maintaining clear channels of communication with the business
• Helping to keep security promises made to users by the business.

The following is a list of items a CISO should consider in the cybersecurity space which support some of the above responsibilities....


Establish development security touchpoints and toll gates
Formalise touch points in the system development and maintenance lifecycle, this can include:

• Integrating simple checks for sanity; logical and behavioural checks as part of functional testing.

• Investment in QA staff to conduct anti-pattern testing and negative abusive testing.

• Leverage automation or managed service provision for in-line technical security validation. If you don't have the skills leverage a MSSP (Managed Security Service Provider) to conduct frequent testing and validation.

Simple fixes can result in huge dividends
The edgescan 2014 and 2015 vulnerability stats report both resulted in a number of stand-out issues which are not super complex and we have been doing similar for many years....

• Patching and maintaining systems or using secure baseline builds in the cloud. 63% of vulnerabilities discovered on 2015 and a similar % in 2014 related to maintenance, configuration and component security/patching. 

• A robust OS/Host/Framework/Component maintenance process will result in a high reduction of security vulnerabilities for any company.

Metrics not all the metrics but the right ones

• Measure the most common vulnerabilities and root causes (Developer bugs/maintenance/insecure component/poor configuration). Such information can be attributed to teams and departments (development, Devops, Admin, Deployment). 

• Metrics on technology platform with the most issues and types of issues can also shed light on where there are awareness weaknesses, technical debt or poor technology choices (unsupported systems etc).

• Consolidated views via GRC/SEIM/BugTracking Integration is important, the last thing you need is another dashboard! 

Security solutions are investments, choose wisely

• Given the trend towards devops and continuous integration/deployment we need to "Push Left" and catch issues earlier be they non-compliance or security vulnerabilities or both. Your solution should support integration with development and an assessment model which maps to your development methodology in terms of frequency of change and deployment model. Root cause and prevention is always better than detection and patch.

• Pushing vulnerability data directly to development assuming validation of discovered issues has been performed. Security vulnerabilities are bugs treat them as such, track them and fix'em.

• Scalability and Accuracy is important in order to handle the level of assessment required which is a function of change and deployment frequency.

• Fullstack solutions - Hackers don't give a sh1t. Lets converge as per the DevOps model and treat security vulnerabilities as "Risk Items". Lets not treat application security and host/network security as separate things. They are all simply paths to being compromised.

Vulnerabilities are bridges which join assets to attackers

• Don't fix all vulnerabilities fix the right ones. - Not all vulnerabilities are equal. understand business context of a vulnerability - risk is a human concept and can (currently) only be understood by people.

• Vulnerabilities come and go - it's not always the developers fault and they can arise even in a static system with little change due to newly discovered issues in your supporting OS/Framework/third-party components.

3rd Party Development and Commercial Off-the Shelf Solutions

• Do your system suppliers code securely, have a secure SDLC - ask them to prove it.

• T&C's should cover quality, security and attribution to a secure development methodology being used.

• Require evidence of assessment, SAST, DAST, Training, monitoring and ongoing improvement in relation to product development.