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

By -

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.









Comments

Post a Comment

Popular posts from this blog

Edgescan, why we do what we do.....

By -
Image
  The cyber security industry is full of solutions to make you more secure. Some are unproven and other approaches work if deployed properly. Our industry is very fragmented. for example a recent "Cyber Defense" award I noticed has 195 categories!  I suppose we need to ask ourselves as companies from time to time why we do what we do?  So, the following post is, I guess, the reason we developed Edgescan and why we believe its a decent solution to help organizations improve and be more resilient in relation to cyber security and system protection.... Vulnerability scanning alone did not work. The idea of software testing software for vulnerabilities is a good one but both sides of the equation may have bugs. Bugs in one side (The target) may result in vulnerabilities, whilst bugs on the other side (Scanner) may result in false negatives and false positives.  Accuracy : To that end we built edgescan as a combination of automation to discover vulnerabilities at scale but  when c
Read more

20 years of Vulnerability Managment - Why we've failed and continue to do so.

By -
Image
Cyber Security: Keeping Pace with Change. Getting breached can really ruin your day. Actually it normally happens on a friday evening as you are about chill for the weekend. The cause of must breaches is not rocket science, its more to do with the poor approach we have accepted because we underestimate the threat actor.  - An attacker does not scan your website/network once a quarter with a commercial or open source scanner or perform an annual penetration test against your systems to see if there is any low hanging fruit, so how do we expect to defend against such an advisory using that approach? Systems change now more frequently than ever due to the ease of cloud deployments and the speed of software deployments due to iterative development techniques. The rate of change increase results in exposures quickly manifesting and the organisation not even being aware of the exposure in the first place. Many organisations dont know what they have exposed on the public Internet. We need t
Read more
By -
Image
The HSE Data Breach and the State of Irish Cyber Security Many years ago, shortly after I founded the Irish chapter of OWASP ( http://www.owasp.org ) (in 2007??) we were delivering free application and software development classes to anyone who wanted them. It was a local low key affair but every class we delivered was "sold out". We have 60-80 folks mostly developers willing to spend 4-5 hours on learning the fundamentals of secure application development and testing. I suppose we felt cyber security was an important issue because that's what we did. At the time many folks in business felt cyber security was an overhead or a "tax" and did not give it much time. A few years later (late 2010) when the the foundation of the NCSC (National Cyber Security Centre) was announced, a few of us (local OWASP Ireland leaders) wrote a number of emails to the Irish government offering free cyber security training. As we were working for a non profit (501.3c) charity (OWA
Read more