Cyber Security As a Shared Service

Organizations often have a hard time wrapping their heads around the right placement for cyber security programs. But cyber security isn’t unique. 

Cyber is just one of many shared services.

Cyber

IAM.

DevOps.

All conceptually different but sharing an origin and continuing linkage to IT. That said, each also transcends IT in modern product driven enterprises. All part of the continuing conversation across the organization.

The White Space of Cyber Security

There is a lot of obvious work done by cyber security teams. The obvious work includes monitoring, implementations, threat hunting, and the like.

That said, there is a lot of cyber security work that takes place in the white space as well, the less obvious places, the quiet tasks that move your cyber program.

Reviewing vendor security questionnaires.

Answering phishing questions.

Analyzing risks in new business acquisitions.

Evaluating new tools for the business. 

These consume time too and generally scale with the growth of the business. 

The more that you can capture the white space tasks your cyber team performs, the more that you can plan and resource for them. Or eliminate the ones that have nothing to do with the core function of your team.

The ones that align to cyber security might be yours to own.

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

Busy As Misplaced Power In Cyber Programs 

The Human Side of Cyber Security

A Simple Priority For Cyber Security Choices

Busy As Misplaced Power In Cyber Programs

Cyber security programs have a strong dependency on other teams for execution to meet the cyber goals of the organization. Other teams also have dependencies on the cyber security team. A common response to requests from either side is “we are too busy.”

On the surface, the answer is clear that they can’t help because the measure of the current level of activity on the team exceeds their bandwidth for additional considerations. 

But, there has become a certain power in the response of always being too busy.

Perhaps, a misplaced application of power, but power nonetheless. 

So, in the absence of clearly defined priorities or a specific timelframe of high priority work, what other things might a team (even the cyber team) actually be saying? 

“We don’t want to arbitrarily say no, but, no”

“We don’t know how to do what you want”

“We don’t know how to prioritize”

“Our value is defined by our level of busy”

The last one is likely the most interesting because constant busy activity leads to constant firefighting which presents many opportunities for heroic actions.  Strange, but all too commonly true. 

So, when a team says no, whether a partner team or your own, it’s important as a cyber leader to engage and understand the clarity and communication of priorities, training, resourcing, and capabilities.

Lastly, a quick gut check may be in order to see if the team is finding too much value in their level of activity. So much value that they aren't doing the things they need to do to continually improve.

Being busy as a team is only valuable to a point. 

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

Mentoring Around Waiting In Cyber Security

Every Cyber Security Program Has a Voice  

Less Heroics Needed In Cyber Security

Mentoring Around Waiting In Cyber Security

It seems like we always have something to wait for in cyber security.

Waiting to see what happens after an alert. 

Waiting for someone to answer an email.

Waiting for something to do.

The Human Side of Cyber Security

As security practitioners, we often forget the human side of cyber.

Someone clicked on a link, entered valid credentials, or put some hardware online without following security standards. Perhaps even a security team member that made a bad decision or missed a key detail.

They’ve made a mistake that put the company at risk or, worse yet, created a security incident leading to a breach. 

Reacting To Cyber Threat Landscape Changes

Any eight character ascii password can be broken in 5 minutes and US$500 in cloud processing costs. 

This change was demonstrated at GRRCon 2019 by a security researcher from Optiv. It may have been demonstrated elsewhere first but this is the first that I have seen time, methodology, and tangible cost associated with the capability. 

Every Cyber Security Program Has a Voice

There is no specific approach for successful cyber security teams. The characteristics of a given cyber team aren't binary but along a spectrum that is driven by external factors and purposeful internal choices. 

Some of the drivers? 

Regulated industry or less regulated.

Directive approach or collaborative.

Compliance focused or risk focused.

IT aligned or enterprise.

The Cyber Security Promise

What is the promise that your cyber security program has made to the organization?

Is the promise simply fulfilling tickets and granting access? 

Monitoring consoles, responding to incidents, and breaking systems?

Or is it something more? Something deeper? More connected to the business?

Are you meeting that promise?

If you are a cyber security leader, think about how you’d answer those questions if asked.

If you are a business leader, start asking those questions. 

Interact until you find a promise that meets everyone's expectations. 

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

An App Security Secret For A Speedy CI/CD World

Striving Towards Cyber Mediocrity

The Only Constant In Cyber Security

An App Security Secret For A Speedy CI/CD World

There is an unspoken secret in the devops world that impacts every application security team.

A startup with a singularly focused product and a few related value streams likely has a very different idea of continuous delivery and devops than a organization that delivers more complex and varying types of value streams that all have to integrate into a core devops process. 

Securing the startup in the above example means planning for the expectation that any committed code can be released to customers at any time. This makes sense because the number of sub-systems that comprise a startup’s system is often small. Any single defect can be easily shipped and either rolled back or quickly fixed without much risk of regression as there generally aren’t a large number of dependencies involved. 

Since startups drive much of the behavior in the application development space, there is an assumption that large, complex applications can be delivered the same way. 

Can complex apps be delivered more quickly with continuous delivery? Certainly.  

That said, the more complex the application is, the more in-depth the various subsystems will need to be integration tested so that we know that they work with each other and manage risk. When speed is paramount, even fully automated testing takes time and most organizations simply aren’t there yet. Unit testing and smoke testing isn’t sufficient even if updates can be shipped quickly particularly when potential regulated information is involved such as personal information, credit card data, etc. on a publicly facing internet application.

If French doors were an organization’s product, unit tests would pass if each door opens separately but significant rework might be required if both doors can’t be opened at the same time. Now, think about the increase the complexity of testing and securing database changes holding sensitive data being made across multiple value streams in a continuous way. That’s just one of N aspects to be considered. 

Application security teams should be collaborating closely with test/QA teams to define common standards, agree on quality definitions, and identify the right timing for various types of testing. The timing will vary greatly depending on the tool, approaches, and level of automation within an organization. 

Good rule of thumb:  Ensure that you are modeling your security methodology based on CI/CD and devops practices of organizations that are building apps with a level of complexity at least equal to yours.  

The fewer dependencies and potential regulatory issues within the value streams delivering an application, the closer to code complete an application can be delivered in a continuous way.  That may not be the hottest startup that delivers dozens of times per day.

The speed of continuous delivery is relative to the alternative methods in which software can be delivered.

There certainly are organizations that have scaled good processes used in startup apps and securely scaled them into larger, more complex applications. There may also be individual components of a large, complex application that can be served well with a very fast continuous deployment model. But an organization likely won’t be successful if they just begin general deployment of continuous updates to an existing internet facing application without significant definition, integration standards, planning, and testing if they want  a stable, high performing, secure application. 

There is a secret opportunity for cyber security teams in the chaos of devops. 

Not-so-secret greatness can be the result. 

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

Responsibility And Accountability in Cyber Security 

Rarely Discussed Real Life Application Security Decisions

Cattle Versus Pets In Securing DevOps Pipelines