A Cyber Security Metaphor

A subset of my team is traveling to an application security summit today a few hours away. It's a compelling event....more valuable than the alternative things that we can be doing today.  

If one of us were taking our own car, there would be little question who would drive. Instead, we have a company vehicle. 

MOVED: The Cyber Security Team’s Continuous Improvement Problem

This post has moved to https://medium.com/@opinionatedsec/the-cyber-security-teams-continuous-improvement-problem-ce5a0f766fe1?sk=2067bd10d696f0d77460933f7bd9f114

Follow me on Twitter for the latest blog updates: @Opinionatedsec1

SEE ALSO

The Gestalt of Ransomware Defense

Why Do We Emphasize Everything At Scale Except Disaster Recovery? 

The Super Secret Source Of Some Of The Best Cyber Threat Intelligence Available

The Gestalt of Ransomware Defense

A gestalt is an organized whole that is perceived as more than the sum of its parts. If you put together a battery, some wire, and a bulb in a certain way and you still only have the three. Align them in a certain way, you also get light. You get something that is greater than the sum of the parts.  

Same parts but you’ve created a gestalt.

You can't buy gestalt. The hard work and planning required to find it doesn't have a price tag.  This means that your email security tools aren’t by themselves a gestalt against ransomware.   

Tools are just parts. 

I'm always astonished that every major ransomware incident produces experts and commentors that opine that backups are the only tools to defend against  ransomware. You’d think that gestalt against ransomware isn’t possible. 

Is it ok to disagree with experts?

Why Do We Emphasize Everything At Scale Except Disaster Recovery?

“Disaster recovery” is often thought about and planned on a server by server basis. A server goes down and gets recovered. A bunch of servers go down and we go to backups.  

The linchpin of almost every org's disaster recovery plan is recovery from backups.  A bad day might consist of an incident that requires recovery from backups. That said, in the worst of really bad days, everything may be encrypted by the bad actors and  even the backups might be compromised. What then?

How prepared are you to recover from, well, from almost nothing? Yiou know....an entire organization that needs to be recovered.....at scale.

Think this scenario is impossible? The June 2018 ransomwareattack the Alaskan borough of Matanuska-Susitna (Mat-Su) is just such an example. 

When we see or have information about such a rare event, we can’t just conclude “don’t click on random attachments” and waste the look at what disaster recovery at scale really looks like.  There are lessons to be learned everywhere, especially in this case.

Random Cyber Security Conundrums

It’s a Sunday morning and I can’t help but try to mentally unravel some conundrums. These have been written in no particular order, just as they come to mind. Beware as I capture a view of the abyss inside me....

------

There are no shortage of social media feeds dedicated to incident response, social engineering, threat hunting, and malware reversing. There are a growing number around application security. Less so around patching. I’m sure that that they are out there but I’ve struggled to find any broad social media coverage for policy governance that aren’t vendors or others trying to sell things.

I sometimes think about the impact that session topics at security conferences. I’d swear that anecdotally 35-50% of the topics have social engineering as the topic. Yet when I look at the details of recent major breaches, few if any of them seem to have been the result of social engineering (unless one loosely associates spear phishing as a social engineering technique). Is this because the social engineering sessions are so effective? or not really relevant to real world breaches? 

Why Operations Engineers Don't Always Transition Into Effective Cyber Security Practitioners

The 99% and the 1%.

Operations engineers have every reason to care about the 99%.

That’s the bulk of the operational load.
The impactful percentage that is easy to measure and needs to be monitored. 

The normal. 

A good cyber security practitioner worries about the 1%.

Those operational rounding errors that the operations team probably doesn’t care about.

The long tail details often not represented in the out of the box metrics.

The anomalies.

Both sides look at the same infrastructure and artifacts in completely different ways. This mindset change impacts everything from threat hunting to security capability building. to prioritization. Many successfullly make the transition in mindset but not everyone does.

Yet, resources and hiring are often skewed towards the 99%. "They do a lot of security work" is the rationale. I'd contend that security work within the 99% is a much different skillset that security work within the 1%.

If the airline industry had a 99% safety record, the remaining 1% would be the reason that passengers probably wouldn’t fly, not the 99% of flights without a problem.

Follow me on Twitter for the latest blog updates: @Opinionatedsec1 

SEE ALSO

The Super Secret Source Of Some Of The Best Cyber Threat Intelligence Available

Develop Security Metrics That Also Are Your Remedy Negotiation  

The Five Pillars of a Successful Application Security Program

Why Cloud Security Requires A Different Mindset

In the legacy infrastructure world, dwell time for bad actors is often measured in weeks or months. 

Bad actors in the cloud don’t have that luxury. That access token they’ve acquired likely without your knowledge often expires in minutes. They’ve come prepared to sprint with automated attacks ready to go. 

The cloud so far has primarily been an automation race run by one side. The wrong side. Organizations will either invest to catch up or perish before they can respond.

Follow me on Twitter for the latest blog updates: @Opinionatedsec1  

SEE ALSO

The Super Secret Source Of Some Of The Best Cyber Threat Intelligence Available

Cybersecurity Needs Style Points  

Security Tool Myths

The Super Secret Source Of Some Of The Best Cyber Threat Intelligence Available

There is no shortage of threat intelligence companies trying to sell you something. Most of what is sold or even available for free isn’t very good.

So where do you go for some of the best threat intelligence for your organization? Shhh…it still has to be a secret. That best source is the information already residing in your own systems. 

What do I mean?

Want to know where you have gaps in your incident response process? Review your previous incidents. What controls would have prevented the incident that you still don’t have in place?

Security Tool Myths

No single security tool will keep your org safe. Actually, even a bunch of security tools strung together probably won't either.

The Five Pillars of a Successful Application Security Program

You've been given task to build out or improve an application security team. Congratulations. You now have a key question to answer: "how will your application security efforts help your organization balance application delivery with application security?" Will you have an answer?

Maybe you are lucky and can slowly work towards an answer to this question since your company has just decided to build out an application development team or, like me in my current role, the answer is a bit more complex since you've moved to an organization in which application development has been going on for years but never has been really governed from a security perspective. Vendors can help but they really are focuse on their own tools.

This post will try to provide you with some considerations for building or improving your application security from something other than a vendor perspective. I draw a lot from my own experience in the field. My journey to becoming a security practioner included some stops leading large high visibility commercial application development teams building API platforms and products for hundreds of millions of users. You've likely used some of the products. Simply by the nature of our product and the frequency with which every appsec defect was reported in the news demanded formalizing an application security program long before appsec was really something defined. Since then, I've defined and implemented a number of application security programs at a number of different organizations.

A key learning from my experience is that there is no "one size fits all" solution to application security. Each organization brings its own unique goals, risk appetite, and requirements. Your organization will need to plan accordingly.

Develop Security Metrics That Also Are Your Remedy Negotiation

I have a few deceptively simple rules about metrics

• We should know the specific question each metric answers
• We should know why each question is important to the program
• We should know in advance what levers to pull if the metric goes off track

The most effective metrics a security program can report to leadership would be clearly linked to the larger organization's strategy.  Anyone would see these as important and make the linkage/value of the cyber security team to the company an obvious one.  

Determining the important things for your cyber security program takes thinking, input, and agreement from other execs. Unfortunately, these linkages probably aren’t represented in the default metrics that come out of the box from your security tools.  Presenting inputs and outputs that are critical to your security program ideally give your leadership team a “check engine light” and an action plan long before there is a real issue that impacts the company.

One of my team's best output metrics right now is the number of revenue producing staff hours lost to security incidents. It’s an ambitious output with a lot of white space and multiple inputs built into it that keep the team focused on executing well in the weeds. It also has an obvious link to a company that wants to sell things.  The executives already know that this metric won’t be zero forever. If the metric begins to move more than a small number of hours, it means that either the security threat landscape has shifted in some way or we are lacking a key control that is impacting revenue. Perhaps it means both. A significant movement in this metric means that I’ll likely have to spend money. Perhaps even unplanned money. The execs already know this too. If I know the average cost of a staff hour, the metric quickly approximates the revenue impact when I present the cost of the new control to compensate for a change in threats. That metric makes what used to be a hard conversation much easier.  

Cybersecurity Needs Style Points

Cyber security teams need to be proficient at building new security capabilities or maturing existing ones. Forgetting capability building means that while your organization may be engaged in tons of activity, they may never be on a path forward that ultimately reduces fire-fighting of disruptive security incidents. However, for all of the benefits, capability building also brings friction for users. With each new security tool or policy, there is some impact on how individual users perform their daily work. Leaders not only feel their own friction but also have to deal with the collective friction of their team as they try to achieve their business objectives. The less regulated the industry, the stronger the pushback over friction will be from leaders. With enough pushback in such industries, projects might be paused post-deployment or not even started. The hard message might be that everyone outside of the security team views this friction as a negative. 

Imagine a very different world in which cyber security teams were incentivized to not just build capabilities, but to complete each project with a plan and execution that causes the minimum amount of friction for users. My personal preference would be to codify the accomplishment of low security friction outcomes into “style points”. These wouldn’t be actual scores or points. The only judges that matter are your users and your execs. As projects become more difficult and complex, there will always be some level of friction and the outcome would need to adjust to account for this friction. However, style points may not be the closest metaphor. A similar but better metaphor might be the system that figure skating used until 2005: there was a first score indicating technical merit (usually the difficulty of the jumps) and a second score representing presentation (artistry). Again, forget any detailed scores. Let’s simply focus on the value proposition of the two categories. 

I’m talking about artistry as part of making the org safely more effective by mimizing friction of security tools or policies. Shouldn’t that be part of the status quo in cyber security anyway? Sadly, it isn’t. 

Intentional Choices For Security Teams and Digital Transformation

Imagine any organization that is beginning or is in the middle of their digital transformation. The organization might even be yours. Excitement is in the air about new technologies such as the Cloud and mobile applications. At the same time, there are a slew of legacy applications and endpoints that aren’t part of the new exciting conversation. 

An organization’s cybersecurity team has no choice but to transform as well. They’ll have actually engage and hold conversations about securing both new and old technologies.  If the team has historically been the “Department of No”, they’ll need to begin to find ways to safely enable “yes”. Perhaps even make no the answer of last resort.  If not, unless they support a highly regulated industry, they’ll be left behind in terms of headcount, funding, and reach. 

You have two choices in terms what you want your org to be. You can transform to an org that adds value to the new company direction or remain the one that provides the same answer as always. 

Which do you think that the CEO or Board would prefer to fully resource? 

Follow me on Twitter for the latest blog updates: @Opinionatedsec1 

SEE ALSO

 Cybersecurity Needs Style Points

The Five Pillars of a Successful Application Security Program