It isn't easy being a CISO. You're often the sole go-between for two very different organs in the corporate anatomy: the engineering teams and upper management. And more often than not, these departments don't exactly see eye-to-eye, either. Perhaps the biggest challenge of all, though, is getting people to understand the security risks that inevitably begin to rear their ugly heads as your organisation starts developing its own applications. It's a challenge on both fronts: developers often don't seem to understand how the their work has a direct impact on their app's security posture. On the other hand, management lacks the necessary technical expertise to make crucial business decisions without considering the implications for security. But you know what's worse? A CISO that can't tell when this is happening. In most cases, it's the security that suffers because it's put on the backburner, in favour of faster releases and more features. As a CISO, you need to be able to pull off the perilous balancing act between what your organisation wants, and what it needs. How often does your apps need to be tested for security? How does a small company build an effective security practice without breaking the bank? And what is the one thing the top CISOs in AppSec have said is the biggest key to their success?
Let's take a closer look at 8 critical things could be doing right now to take your CISO game to the next level.
This is perhaps one of the biggest oversights among CISOs, according to Mark Willis, security veteran and CISO of Bluescape. "You can't be a good CISO if you don't understand the business," he said in an interview for our AppSecEngineer podcast. "No business, no security. You've got to understand what the top priorities are for your organisation." On the face of it, that might not seem obvious. You're a security guy, so why would you need to learn about your company's whole business model? For starters, it's important to recognise that any organisation's business strategies will in some way impact their security practices, either directly or indirectly.
For example, if your company's migrating into a cloud-native environment with a focus on containerised apps, your security practice needs to shift to meet those needs. Working closely with other departments at your organisation - including the decision-makers in management - is how you ensure AppSec keeps up with the pace of change of development.
This one applies both to people working towards a CISO job and those that already occupy that position. As the person overseeing security operations at your organisation, you can't expect to be able to see the 'big-picture stuff' if you don't have a firm grasp on the basics. You're supposed to ensure everyone else is doing their job right, but you can't really do that if you don't know exactly what they're doing in the first place. Dinis Cruz, CTO and CISO of Glasswall, was one of the first guess on our AppSecEngineer Podcast. "I made a very conscious decision to only go to senior management later in my career," he told us. "It meant that by the time I got into CISO and CTO, I was one of the most technical people in the room. I'd be able to follow any conversation. For example, I'd be able to understand the cloud on a native level, while someone with no experience programming the cloud sees it as an abstract concept." Mark Willis echoes this sentiment. "You've got some CISOs out there that might say they're experts in AppSec," he said, "but they can't tell the difference between C++ and Python. They wouldn't know how to run a code review." When you've already run the marathon and jumped the hurdles, you know exactly what you're up against, and it also means that if you need to get your hands dirty, you're actually well-equipped to do that.
"I find that being technical is a massive asset," Dinis said, "because you understand in great depth what is and what isn't possible. So when you delegate, you know the difference between something that should be easy and something that isn't going to work. As you get more senior and control more of the budget, those things are very important."
One of the biggest challenges small companies face is building a competent security team for 'twenty-five cents to the dollar'. Because let's face it, the people your really want to hire are already working somewhere else, being paid salaries you can't afford. The biggest organisations skim off the top layer of potential hires, leaving smaller companies with a less experienced, possibly less qualified pool of candidates. So how are the smaller players supposed to compete with the Googles and Apples of the world? The short answer: nurturing the right kind of talent. Mark Willis gave us the long answer. "What I'm looking for is people that are hungry, that aren't know-it-alls," he said. "Someone who can roll up their sleeves and get the job done. I know it when I see it. I'm looking for the person that's actually built something; who was willing to go into a new situation maybe not knowing everything, but they figured it out." As a CISO for a smaller company, you're not always going to be able to hire someone perfectly suited for the role you want (that might not even be desirable in all cases). But finding someone that can grow to fill those shoes is who you should really be looking out for. A person that's willing to learn is a person that can get the job done.
"In this business, we want to help people grow and expand," Mark said. "They need to be able to show that they've done things. You don't want to stifle people , you want to build talent and do great things together."
[caption id="attachment_4535" align="alignnone" width="692"]
via we45[/caption] In a recent study, it was found that organisations that scan their apps 300 times a year fix 3 times more bugs and have 5 times smaller backlog of vulnerabilities than those that scan their apps a couple of times every month. Security debt happens when you let so many vulnerabilities build up without fixing any of them that you now have a virtually impossible number of them to remediate, and it just gets worse over time. In fact, the fix rate for vulnerabilities reduces by half with each passing month that they remain unresolved. But why is that? Why does more frequent scanning lead to a better chance of fixing those vulnerabilities? Well, in that same study, it was found that the more often you scan your apps, the less time it takes to fix them. Where companies that do 1-12 scans a year fix vulnerabilities in 68 days, companies that scan more than 260 times a year take just 19. That's a reduction of more than 3.5 times.
People in AppSec treat Threat Modelling the same way they treat their Netflix watch list: they've always been meaning to get around to it at some point, but they somehow never have the time. The problem with this attitude is that it fundamentally downplays the importance of Threat Modelling in the modern security landscape. Having good documentation and a solid grasp on how your application responds to a security threat isn't just a 'nice-to-have', it's an absolute necessity, especially with how complex apps (and their attack surfaces) have gotten in the last few years. But Dinis Cruz takes this one step further. "The message on Threat Modelling is not actually for the security team," he said. "I view it as a technique to document and create a real-world view of the application, where one of the side-effects is finding the security risks, but the most important result is how the application itself works. That's how we've had success with developers: looking at it from the perspective of documentation-as-code. It allows you to ask really good questions."
Threat Models are a great way to help you make rational decisions because it eliminates the guesswork. When you have all the information you need to make a solid, informed decision, you're not going to have make leaps in judgment and hope for the best. Threat Models give you the context you need - from the perspective of both technology and business - to visualise not just what you need to be doing, but what the ramifications of those actions are.
Not all vulnerabilities are created equal. Obviously. But it's more important than ever to understand how to pick and choose which ones to resolve first. Now, don't get me wrong, you absolutely should try and remediate as many vulnerabilities as you possibly can, and in an ideal world, that would be all of them. But this is the real world, and we have to be honest about what we can and can't do. "Developers don't have a lot of time to fix code," said Mark Willis. "You need get right to the point, give them the High and Critical vulnerabilities to focus on. If we see Mediums and Lows in a code review, we'll get to that later. You've got to be able to go after the Criticals and Highs."
More often than not, it's the more exploitable vulnerabilities that get, well, exploited. Those are the low-hanging fruit you need to make sure an attacker can't get their hands on. Once you've taken care of the really serious ones, you can look at the ones you have left.
It's been a common refrain in the AppSec industry these last few years: developers need to make an effort to understand security. After all, they're the ones writing the code, right? If they write more secure code, it means fewer vulnerabilities to report, and as a result, fewer vulnerabilities to fix, too. But what about the converse? Security engineers and developers are often at loggerheads because they just don't understand each other's problems. The problem is, developers are often caught in the crossfire between two sides: management expecting faster releases and imposing tighter deadlines, and security expecting more vulnerabilities to be fixed to make the next release more secure. It's just not possible to expect developers to care about security the way a security professional would. That's why AppSec engineers need to learn how to tailor their security reports to a developer's needs. "I think an AppSec professional needs to have a background in code," Mark Willis said. "It helps you have that understanding of what the life is like for a developer, so when you approach them as a security engineer and you're asking them to do something, you've got that empathy." It's never a bad thing to get your developers more savvy with security; in fact, that's how you ensure they start writing secure code. But when AppSec engineers meet them halfway, they're not just saving huge amounts of time that developers would waste trying to figure out how to fix bugs. They're helping ease the friction between two teams that, really, never should have existed in the first place.
So your organisation's launching a new project that's totally different from what they've been doing so far, new technology stack and everything. It's natural to think hiring an expert in that particular field of AppSec is the way to go, especially if your current can't properly fulfil the security requirements. But there are a whole lot of hidden costs to a simple decision like that. Just to give you an idea of what I mean, let's look at the cost of hiring an engineer. If we add up the amount of time it takes to review resumes, screen candidates and interview them, it can take as much as 65 hours to just hire one person, resulting in an expense as high as $22,750. And that's not even accounting for the loss of productivity as the employee gets used to a new work environment and is still learning about all the internal systems at the organisation. In fact, it takes as much as 5 months for a new hire to reach the full productivity potential. These are not trivial figures, especially for a smaller company. The alternative, training, has far better return on investment. Because you're just spending on upskilling the talent you already have, you can focus your effort in exactly the domain you're entering. Is your organisation moving to containerised apps? Train your AppSec engineers in Container and Kubernetes security. If you're moving to the cloud, your engineers can learn exactly the skills they need to move things forward. Security training is one of the most valuable ways you can invest in your team, not just from the perspective of saving money from not having to hire someone new, but getting your entire workforce on a level playing field where everyone's equally skilled.