1.2. Employ a CVE Detection Tool
1.3. Engage an External Penetration Testing Firm
1. Platform Security … and Sleeping at Night
I’m not going to pretend to be an expert on cybersecurity, and this section is going to be a short one. For one, approaches for securing platforms are thoroughly documented and highly available online, and frankly, I don’t have the right to; cybersecurity is a highly technical practice area of its own. However, I have managed platform security from both the software and infrastructure perspectives, and there are two meaningful takeaways from my time doing so that I feel are worth sharing. Simply, you need intelligent tooling built into your SDLC to protect your application, and you need neutral penetration testing partners to help prove you’re secure to the maximum extent possible.
Today hackers are increasingly well-organized companies which run as “legitimate” businesses where people arrive for and leave work on a daily basis, just like the rest of us. They operate hacking as a service, operate a bottom line, and care about return on investment. They are experienced, excellent technicians with automation tools designed specifically for identifying holes in your applications and infrastructure. All it takes is a well-targeted phishing attack (or any of a range of other attack vectors) to infect the right person’s computer, and there aren’t many steps between there and the privilege escalation required to access your back-office applications, the back end of your platform, start extricating data, and/or install and trigger ransomware.
Once a hacker has one of your employees on the hook, as far as the software you’re building is concerned, a secure web application can make such an attack at the very least much more difficult or render it completely ineffective. Unless you’re talking about state actors and/or you’re at a particularly high profile or strategically important company where a persistent threat is almost certain no matter what, being businesses, these hackers don’t want to sink too much effort into a company that has itself all buttoned up. Hacking as a service is cheap these days, but even those guys need to remember their bottom line.
From the infrastructure side, the entire IP address namespace is port scanned by malicious actors every day; this takes only minutes for an advanced actor to do. Your visible edge and compute assets are almost certainly within reach, and any vulnerability is certain to be considered a starting point for penetration. Any unmanaged opening (which is to say it’s open and you don’t realise it) presents a massive risk as it can provide an attack vector to ultimately access your data directly.
You need to operate with the attitude that the hackers are much more advanced than your engineers (and almost certainly are) and put strategies in place to mitigate the risk. There is always risk here, but with the right tools, mitigation doesn’t have to be difficult either.
1.1. A Rushed Developer is an Insecure Developer
Do not trust that your engineers know how to write secure code, and even if they do, don’t trust that they are. Just don’t. A lot of developers just don’t know what patterns make their code vulnerable. One naïve slip-up by an undereducated developer or even a senior developer operating under duress can make an otherwise secure application porous overnight. Your whole business is instantly put at risk, and you might not know until it’s too late. This is a terrifying prospect, and it speaks to the massive responsibility you have as a technology leader to do everything possible to detect and prevent this scenario.
The problem is that as a technology leader your code is a long way away from you, and there is a lot of it. Your platform may have dozens of accessible APIs and UI elements – any one of which could be vulnerable. The most well-defined code review process and the most detail-oriented code reviewers are very likely to miss issues, and besides, no human being wants to do that job on every commit. You need a tool to catch these, and your developers need education.
1.2. Employ a CVE Detection Tool
There is a multitude of Common Vulnerability and Exposure (CVE) detection tools on the market, and if you don’t have one in your build pipeline you’re operating at massive risk, and fixing this problem is literally a race against the clock with those who would attempt an exploit. If your platform is a web application, getting a CVE detection tool in place should be one of your highest priorities, right up there with getting your critical data routinely backed up into separately hosted air-gapped storage. The engineering inefficiencies you’re working to improve won’t matter if your platform is hacked and your reputation is in tatters.
Choose a tool that integrates directly into your CI/CD pipeline that can prevent commits of vulnerable code and stop the build – you must know every single time a developer introduces an issue. Secondly, make sure the tool understands the concepts of source and sink and can detect when data is passed insecurely from inputs (UI, API endpoints) directly to the underlying data layers. Lastly, make sure the developers become educated in secure coding disciplines and conduct trainings each time a new vulnerability is detected. You have to be must active and get on these. The Architecture Committee is a good place to start in creating your education plan. One tool with which I’ve worked – ShiftLeft – actually integrates the educational component of this process directly into the tool and is directly accessible to the developer.
1.3. Engage an External Penetration Testing Firm
If you’re in a position to afford and find the highly skilled engineers with a hacker mentality whose sole job is to locate ways to penetrate your software, congratulations. For the majority of us that cannot, you need to form a relationship with an external penetration testing firm. Penetration tests can be expensive exercises to conduct, but the cost of being caught by an exploit are so much greater that it’s a cost you just have to be prepared to swallow.
If the sticker shock of an external penetration testing engagements is high, consider a couple of things. Firstly, consider that you’re paying for a team of engineers who have broad experience across a range of platforms, and you don’t have to manage them yourselves. Depending on the size of the platform, the price of a single engagement may be less than or comparable to a single employee of your own. Moreover, their teams of engineers are constantly cross-training in hacking techniques and so you get the benefit of that shared knowledge too. Lastly, these teams go in knowing nothing about your system, and use every technique they know to probe its across both the infrastructure and software realms to see how many holes you have in your system. This eyes-wide-open mentality is an asset.
One other thing to think about if you do have internal penetration testers is that over time they may become so familiar with the platform is that their system knowledge becomes great but they can become “vision impaired”. This is a risk not dissimilar to a developer testing their own code; they know how the code operates, and they selectively test only what seems important. If your penetration testers are using an approach whereby every exploit they attempt is automated in a tool suite of their own design this will be largely mitigated, and you can run your penetration tests very reliably with confidence you’re getting consistent results.
At the risk of skimming the outer limits of the CISO atmosphere momentarily, as a parting thought on this topic, consider again that your people are generally your greatest vulnerability, and that keeping them honest and detecting weaknesses is important. I’ll do little more than drop the thought that some penetration testing companies can go so far as to attempt to physically enter your premises under false pretences to leave intelligence gathering devices to test your defences. These efforts require uniquely qualified individuals on the part of the testing firm, and these are very expensive engagements.
Next Up
The previous technology management topics discuss the "whats" and "hows" of managing the more nuanced aspects of developing a software platform, but the rubber has to hit the road by way of actual execution. It isn't just as easy as executing Scrum - there are many considerations that need recognition and active management above and beyond this. The next posts focus on these considerations, relationship dynamics, and ideas on how to build them into your SDLC.
You can view my next post titled "Lessons in Scrum" here.
No comments:
Post a Comment