Virtual CISO: How to sleep well at night without experienced Chief Information Security Officer (featuring DevSecOps, SSDLC, vCISO)
Let’s face it – application security (AppSec) and compliance have never been sexy, but there’s no need to convince anyone they are not optional. What needs emphasising, though, is that apart from the risk factor that has been played over and over again, there’s also a significant positive driver – customers. Enterprises and regulated (but often smaller) businesses highly value partners who meet governance criteria and can easily demonstrate it. As a result, running a tight ship tends to massively simplify the procurement process and even increase sales altogether.
Over the past two decades, IT has shifted left with DevOps practices delivering a development infrastructure that’s fully automated and operating on a self-service basis which improved development productivity and velocity beyond recognition. Nowadays, you are expected to deliver software releases even several times a day to keep up with the market. In this fast-paced environment, there is simply little time for post-development security reviews of new software versions or analysis of cloud infrastructure configurations before the next development sprint begins. Now, DevSecOps is an expansion of the same concept based on a further culture shift that aims to bake security into those rapid release cycles (as opposed to being a stage at the end of Software Development Life Cycle [SDLC]). Such a change does not happen by merely a committed decision – instead, it needs to be continuously reinforced – a natural thing for a CISO in the business. But how to get one?
Life without a CISO
Over 45% of businesses do not have a CISO position filled, although, at the most basic level, GDPR nominations are required. It’s not that companies don’t value or want cybersecurity leadership – it is just getting harder and harder to find and retain these individuals. As things stand, it’s not difficult, however, to make an argument that every software and test engineer (or even an admin) is a security engineer, as in practice, even the smallest decisions can (and do) translate to the security of their business as a whole. The problem, though, is that the traditional approach to security within SDLC too often ignores the context and focuses on vulnerabilities on a micro scale (for example, individual ticket level) – not the whole user journey that’s being created or changed. Security testing tends to come up too late in the production process (sometimes even outsourced via pentests). As a result, it ends up tremendously expensive and disliked (that’s assuming the problem is picked up and fixed in the first place – if not, think incident response, risk assessment, the fix itself, more testing, plus a lot of the time a reputation cost or even a ransom or penalty ).
At this stage, it is clear that a single dedicated CISO that can be effectively outsourced to be responsible for the complete security of the application is not viable for the vast majority of cases. While the big enterprises do have budgets for luxuries essentials such as the red and blue teams and possibly a whole team of security specialists to deal with obvious bottlenecks in an imperfect process (e.g., multiple sprints closing within a short time space causing demand spikes as an obvious issue), the same cannot be said for the challengers whose risks are just as high, but traditional ‘model’ solutions are simply out of reach for them.
Levelling the AppSec field
Even though you try your best to simplify them, your technical estates become increasingly sophisticated, and the competitive landscape only results in the number of initiatives your business needs to juggle to grow exponentially. With that in mind, no CISO nor security architect could become the single point of failure as they are physically unable to aggregate all functional requirements and augment them with non-functional, security ones.
That does not mean, however, that the battle is lost -far from it. Just like DevOps commoditised the development infrastructure ecosystem, an analogical approach is starting to take place with AppSec, where the owner can, and should, shift left in the SDLC, regardless of the budgets. Instead of passively addressing issues flagged by pentests (i.e., well after the work is done), the SDLC can be adjusted to accommodate security-first culture from inception.
More often than not, it is at the very least a surprise to many technical leaders that the majority of the pentesting is not a manual specialist task but a very automated process. And if that’s the case, a natural realisation should be that the same automation should (and can) be moved up the development lifecycle where it is much more likely to reduce the cost of change.
Don’t get your hopes too high, though – automation is an essential and seemingly a passive aspect (even if you implement Dynamic Application Security Testing [DAST] and Static Application Security Testing [SAST] as part of your testing protocol, you still have to monitor and police the console!) – making the whole SDLC security-driven (‘i.e., SSDLC’) considerably more refined.
My ambition here is not to scare you but at least inspire you to consider taking the first steps, and there is undoubtedly more low-hanging fruit.
First steps to focus on
In my experience, the following three pillars tend to make the biggest difference overall and provide the highest ROI:
- Quality of testing (automation)
- Quality of coding (training and onboarding newcomers, checklists, plugins)
- Quality of design
While we have already talked a little bit about testing, the most difficult change to make is the design and architectural flaws. It is hard because that’s where a policy change most visibly becomes the culture change I alluded to earlier, rather than a tool or add-on that you can add to software that has recently been recognised by OWASP (Open Web Application Security Project).
Starting with secure application design
The element that is typically missing in solution design is threat modelling, i.e., a setup where security consideration becomes a pre-requisite of the requirement being finalised. While there are no magic pills or simple pieces of advice that you can generically apply to every setup, the foundations of threat modelling can be distilled into 3 aspects:
- Understanding the threat actors – i.e., who may be interested in compromising your system
- Defining the threat itself – i.e., what are you afraid of, what is the risk
- Identifying the possible attack vectors – i.e., how they may try to get it done
Once you have an idea of the base threat models (OWASP’s list of 40 original sins is a great place to start), you’re able to incorporate the abuser stories (security requirements) into the actual user stories being developed, and those can then be easily augmented with appropriate test cases and security metrics.
By this stage, you’re likely thinking that what I am proposing sounds incredibly disruptive and expensive. In reality, however, not only is such a mindset change considerably cheaper, but in the long run, it’s just as important to remain pragmatic in how you implement the shift. You quickly realise that not all requirements introduce equal risks, and hence it’s only natural and sensible for the user stories to be filtered against threats to the model, which is a form of prioritisation.
Demystifying application security
The message I am trying to get across is certainly not that you don’t need a CISO – just don’t assume they ride to work on a white horse. The transition from SDLC to SSDLC is a convoluted one, and while there is low-hanging fruit to be picked, there are also no universal truths or one-size-fits-all. And that means a CISO needs to continuously monitor that transition and have the authority to pivot should the process break or become ineffective at any stage.
Let’s be realistic – things like abuser stories will not magically solve all your problems but are a great starting point. As the process matures, there will still be increasing pressure from the business to drive the costs of the secure development process down – and that’s where things like checklists for particular system types and guides (secure design patterns, relevant reference architectures) will start to come handy. It sure will take some time to distil general solutions to security problems that you can apply in different situations, but eventually, you’ll start to automate and centralise the knowledge and ensure all engineers get to know the enemy – it will be in their blood.
The future is brighter than you think
The further left you manage to shift the security mindset within the SDLC (testing-> coding-> design) the bigger the impact you are going to experience. If you don’t (or can’t have) a dedicated CISO to orchestrate and own this transition, let it not stop you – there are virtual (vCISO) options available too.
These typically will not only get the ground running quickly but also tend to feel less obliged to play nice with office politics. So while you should not underestimate the task at hand, there is also no reason not to start questioning the status quo now and begin to make small steps with a huge impact.