Tag: #team

Are Traditional IT Roles Still Relevant In Today’s Modern Security Org?

As more and more businesses shift to the cloud and micro-services, the scope of responsibility for security and operations gets pushed up the stack. As a result of this scope compression, teams no longer need to worry about maintaining physical infrastructure like deploying servers, provisioning storage systems or managing network devices. As this scope falls off, the question becomes – are traditional IT roles still relevant in today’s modern security org?

Cloud Service Models

First, let’s talk about cloud service models most companies will consume because this is going to determine what roles you will need within your security organization. This post is also assuming you are not working at a hyper-scale cloud organization like AWS, Azure, Google Cloud or Oracle because those companies still deploy hardware as part of the services they consume internally and provide to their customers.

Infrastructure as a Service (IaaS)

Infrastructure as a Service (IaaS) is what you typically think of when you consume resources from a Cloud Service Provider (CSP). In IaaS, the CSP provides and manages the underlying infrastructure of network, storage and compute. The customer is responsible for managing how they consume these resources and any application that are built on top of the underlying IaaS.

Platform as a Service (PaaS)

In Platform as a Service (PaaS), the cloud service provider manages the underlying infrastructure and provides a platform for customers to develop applications. All the customer needs to do is write and deploy an application onto the platform.

Software as a Service (SaaS)

With Software as a Service (SaaS) customers consume software provided by the cloud service provider. All the customer needs to worry about is bringing their own data or figuring out how to apply the SaaS to their business.

IaaS, PaaS & SaaS Cloud Service Provider Logical Model

As you can see from the above model, organizations that adopt cloud services will only have to manage security at certain layers in the stack (there is some nuance to this, but let’s keep it simple for now).

What Are Some Traditional IT Roles?

There are a variety of traditional information technology (IT) roles that will exist when an organization manages their own hardware, network connections and data centers. Some or all of these roles will no longer apply as companies shift to the cloud. Here is a short list of those roles:

  • Hardware Engineer – Server and hardware selection, provisioning, maintenance and management (racking and stacking)
  • Data Center Engineer – Experience designing and managing data centers and physical facilities (heating, cooling, cabling, power)
  • Virtualization Administrator – Experience with hypervisors and virtualization technologies*
  • Storage Engineer – Experience designing, deploying and provisioning physical storage
  • Network Engineer – Experience with a variety of network technologies at OSI layer 2 and layer 3 such as BGP, OSPF, routing and switching

*May still be needed if organizations choose to deploy virtualization technologies on top of IaaS

Who Performs Traditional IT Roles In The Cloud?

Why don’t organizations need these traditional IT roles anymore? This is because of the shared service model that exists in the cloud. As a customer of a cloud service provider you are paying that CSP to make it easy for you to consume these resources. As a result you don’t have to worry about the capital expenditure of purchasing hardware or the financial accounting jujitsu needed to amortize or depreciate those assets.

In a shared service model the CSP is responsible for maintaining everything in the stack for the model you are consuming. For example, in the IaaS model, the CSP will provide you with the network, storage and compute resources you have requested. Behind the scenes they will make sure all these things are up to date, patched, properly cooled, properly powered, accessible and reliable. As a CSP IaaS customer, you are responsible for maintaining anything you deploy into the cloud. This means you need to maintain and update the OS, platform, services and applications that you install or create on top of IaaS as part of your business model.

Everything Is Code

One advantage of moving to the cloud is everything becomes “code”. In an IaaS model this means requesting storage, networking, compute, deploying the OS and building your application are all code. The end result of everything is code means you no longer need dedicated roles to provision or configure the underlying IaaS. Now, single teams of developers can provision infrastructure and deploy applications on demand. This skillset shift resulted in an organizational shift that spawned the terms developer operations (DevOps) and continuous integration / continuous delivery (CI/CD). Now you have whole teams deploying and operating in a continuous model.

Shift From Dedicated Roles To Breadth Of Skills

Ok, but don’t we still need traditional IT skills in security? Yes, yes you do. You need the skills, but not a dedicated role.

Imagine a model where everyone at your company works remotely from home and your business model is cloud native, using PaaS to deploy your custom application. As the CISO of this organization, what roles do you need in your security team?

From a business standpoint, you still need to worry about data and how it flows, you need to worry about how your applications are used and can be abused, but your team will primarily be focused on making sure the code your business uses to deploy resources and applications in the cloud is secure. You also need to make sure your business is following appropriate laws and regulations. However, you will no longer need dedicated people managing firewalls, routers or hardening servers.

What you will need is people with an understanding of technologies like identity, networking, storage and operating systems. These skills will be necessary so your security team can validate resources are being consumed securely. You will also need a lot of people who understand application security and you will need compliance folks to make sure the services you are consuming are following best practices (like SOC 2 and SOC 3 reports).

What Do You Recommend For People Who Want To Get Into Security Or Are Deciding On A Career Path?

I want to wrap up this post by talking about skills I think people need to get into security. Security is a wonderful field because there are so many different specialization areas. Anyone with enough time and motivation can learn about the different areas of security. In fact, the U.S. Government is kind enough to publish a ton of frameworks and documents talking about all aspects of security if you have the time and motivation to read them. That being said, if I was just starting out in security I would advise people to first pick something that interests them.

  • Are you motivated by building things? Learn how to be a security engineer or application security engineer. Learn how to script, write code and be familiar with a variety of technologies.
  • Are you motivated by breaking things? Learn how to be a penetration tester, threat hunter or offensive security engineer.
  • Do you like legal topics, regulations and following the rules? Look into becoming an auditor or compliance specialist.
  • Do you like detective work, investigating problems and periodic excitement? Learn how to be an incident response or security operations analyst.

Ask Questions For Understanding

The above questions and recommendations are just the tip of the iceberg for security. My biggest piece of advice is once you find an area that interests you start asking a lot of questions. Don’t take it for granted that your CSP magically provides you with whatever resources you ask for. Figure out how that works. Don’t blindly accept a new regulation. Dissect it and understand the motivation behind it. Don’t blindly follow an incident response playbook. Understand why the steps exist and make suggestions to improve it. If a new vulnerability is released that impacts your product, understand how and why it is vulnerable. The point is, as a security professional the more understanding you have of why things exist, how they work and what options you have for managing them, the more skills you will add to your resume and the more successful you will be in your career, especially as your security org collapses roles as a result of moving to the cloud.

Exploring The Advantages and Disadvantages of Centralized vs. Decentralized Teams

This blog post is part of the Compliance Corner Series developed in partnership with Milan Patel. This series includes a variety of discussion topics around the intersection of security and compliance. The series includes blog posts, live web streams (with Q&A) and podcasts.

What is more effective – A decentralized or centralized security and compliance team? What are the factors you need to consider, what are the pros and cons of each model, does company size matter, are they simply analogs of organizational maturity or should leaders consider one model over another model for their org?

  1. When leaders are creating or maturing their organization should they consider a centralized or decentralized organization structure?

Lee: If you have the opportunity to create or modify your organization I personally prefer a centralized organization structure. This is because it concentrates the roles, responsibilities and authority for security into a single function that can offer governance and all of the additional expertise expected of a security organization. The rest of the business knows where to go and who to talk to for all security issues. I have seen problems arise in both decentralized and heavily matrixed organizations because it confuses the roles and responsibilities of the function. Who is actually responsible for making security decisions if major parts of security are spread out across the organization? Sharing resources doesn’t really work very well because it is confusing for the individual team members and when sharing resources one side typically loses out to the other side. I have also seen shared resources get mis-used or repurposed for things other than security. This doesn’t mean the security team can’t place resources in different parts of the org, but they should report into and be owned by the security function. In my opinion whoever is responsible for the budget and the headcount truly controls that resource and decentralizing the budget and headcount causes problems.

Milan: Business leaders must first consider what role they want their compliance organizations to have. Will their compliance team actually offer governance, or just auditing? Are they going to cover corporate policies, or just audit frameworks that attest to customer reports? These are important scope questions to answer before setting up (or maturing) a compliance organization. It can drastically change how you fund and scope skills for the team, and whether a decentralized team will meet the overall risk management and corporate goals.

Investment size must also be considered, I get that question all the time, “How much should a business invest in compliance?”. I have seen everyone from flat personnel-project based funding, to actual percent of overall business operations spend. I focus on scope first, as then you can directly cost out what the deliverables/responsibilities are. Governance will drive a big factor of centralized or decentralized teams. Governance requires authority, charter, and appropriate level of independence to actually hold teams accountable. In a decentralized model, governance becomes much more difficult, as the fox ends up guarding the hen house.

  1. Does company size, organizational maturity or other factors influence the decision to have a centralized vs. decentralized organization?

Lee: Company size can definitely influence the initial decision to create a centralized or decentralized function. Smaller organizations or startups may not be able to justify the initial cost of a dedicated security leader and may lump this responsibility under the CIO, CTO or Chief Counsel. As a result the security function may initially grow as a decentralized function until the organization decides it is either time to offload the original leader or they realize they need more specific security leadership and it is time to build out a dedicated function.

Organizational maturity can also impact the decision. Immature organizations may struggle to effectively use decentralized resources and so the weaker the organizational culture the more a centralized security organization will make sense. However, in really large organizations it is common to see a hybrid approach which I like to call a federated model. In a federated model you have a centralized security organization that sets policy, governance, manages risk, makes decisions and has all the authority for anything security. Business units within the large company then staff specific security resources based on expertise for specific industries or to help navigate their specific security and regulatory requirements. This can be advantageous in terms of presenting a single view of overall risk, consolidating processes and leveraging economies of scale for purchases to get a better price for tools or contracts used for security across the organization.

Milan: Company size, and breath of products, can definitely influence the model. In smaller companies, there will likely be less resourcing (and complexity) to consider, which makes a centralized model more affordable and practical. You are not going to have much ability to fund a larger team (and wouldn’t likely need it), so a centralized model pretty much is the only option.

In larger companies, decentralization is used (and we’ll talk about advantages and disadvantages later), but the better model is hub and spoke. A strong central team, chartered with governance, but small “spoke” compliance teams that are the boots on the ground in the team. Small presence that can keep engineering on track, participate in design reviews, threat model reviews, and know enough to ensure that engineering teams and products are on the right track from the start. They also can drive best practices for that team, but they are based on the central team requirements, and can escalate to the central team (that ideally has a governance charter) to ensure adherence at the right senior level.

  1. What are the advantages and disadvantages of each model?

Lee: Centralized models offer consolidation of budget, resources, governance, responsibility and authority. It presents a single function that the rest of the business can go to for anything security related. Centralized models are typically more efficient because it avoids each group having to create and duplicate resourcing, tooling and processes. The one downside of a centralized model is if the security organization forgets that the rest of the business is their customer then it can become extremely difficult to interact with that group who effectively becomes a gatekeeper for business progress.

Decentralized models can offer some initial advantages when companies are extremely small. This is typical during startups or when you are operating in a mode where everyone is doing a lot of different jobs. However, this usually isn’t sustainable long term. I also find people who operate in this mode usually can’t scale to a larger organization where more governance is required. Decentralized models are also more prone to duplication of resources, technology and processes because there isn’t a single leader coordinating strategy and investment. Decentralized functions can also run into problems where the resources are misused or go “native” and stop performing the intended security role. Decentralized functions may end up with different levels of maturity across the different groups in the organization, which can make it difficult to obtain compliance certifications or to standardize processes and technology for a unified approach to security.

Milan: In general, a centralized structure offers the best overall coverage and governance. You can set consistent policies and practices across multiple organizations, which inherently will reduce risk as it’s easier to ensure consistency, and accuracy with one process vs many. You also can provide more controls to validate continuously that processes are working, plus attest much easier. Continuous compliance in a cloud environment is basically the norm now, but not all organizations, especially those with a decentralized model, can effectively ensure compliance of many regulations that come in and now must be enforced at the corporate level, and not just at the product level.

You also reduce cost, as having one set of compliance experts is cheaper, and can provide more optimization of skills. In a decentralized model, you end up having to hire more individuals, as you must replicate specialized skills in multiple areas. 

One aspect that is often overlooked in centralized vs decentralized is pricing power. For compliance, for instance, you can collective bargain auditing to drive better prices in a centralized model. In a decentralized model, every team is determining it’s own bidding and metrics, which basically allows for suppliers to cost every team as individuals, reducing the overall negotiating power of the company. In a decentralized model, you usually also have more junior leaders (as the team and overall scope is smaller), and that dilutes the overall governance credibility, as they are not truly objective, as again, this can give the impression of the fox guarding the hen house.

  1. Is there a clear winner here or is this more of a dogmatic approach / “it depends” type of answer?

Lee: Obviously there is always an “it depends” type of answer, but I personally think a centralized team offers far more advantages than a decentralized team. I have operated in decentralized teams, startups, and heavily matrixed organizations and they have all had incredible inefficiencies, process problems, lack of technological standardization and contention between the leaders in control of the different resources. While anyone can demonstrate leadership, the reality is there can only be one leader for a function. If you want to build a strong and effective security organization my personal recommendation is to avoid the decentralized model and strongly advocate for a consolidated, centralized function for all of the reasons I listed above. 

No matter what size your company is, at some point your business will get big enough that it will either need to transition to or will need to build a centralized security org. Even when your company gets truly massive a centralized security organization will offer tremendous advantages for coordinating the rest of the functions across the business. This doesn’t mean you can’t have specific expertise embedded within the different lines of business, but there should be one overarching function that sets strategy, governance and has the authority to coordinate everything related to security across the organization.

Milan: I am going to lead off with a “it depends”, but “it depends” on what the SLT wants the function of the Compliance team to be, and how they want them to operate. For example, if they want what they “should” want. Corporate SLT should want an independent compliance organization that has the charter and weight to actually drive governance and accountability. Any decisions made by an engineering leader where the compliance team reports directly to them will be suspect if there is an issue, as how can compliance be seen as impartial if the decision can be overturned by the product or engineering leader directly? Did the right conversation happen, does that decision align with similar decisions with other product groups/lines of business? It can be a real problem if there is an issue and companies have to explain.

That is very difficult in a decentralized model. In a decentralized model where the compliance team, which has to drive hard messages and needs to engineering leaders, are they truly independent and will they speak up, as they tend to be mostly more junior, without any real organizational or peer power with the teams they are supposed to govern? The answer I’ve seen is rarely. I’ve seen and worked with many compliance teams that are frankly afraid to raise issues, or particularly escalate (and if they would escalate, who would they escalate to, as it would be their own management that signs their pay stubs). I’ve seen it both on the compliance and security side, where even mid level leaders will not raise or push issues, as they are worried for their jobs. It’s very difficult to find compliance teams and leaders that can truly be “politically unencumbered” in terms of raising issues, when they report to the fox that likely already doesn’t like having to do compliance work. 

I believe that a strong and chartered central team, made up with the right personnel that understand engineering and can translate, and govern engineering compliance practices is the overall best option, particularly for larger organizations where standardization and efficiency must be improved. In a large company, compliance “spokes” with specific charter are important, as it’s the only way to scale the appropriate knowledge down to the teams.

The Different States Of A Security Program

It may be obvious, but every company that has a security program is in a different state of maturity. As a CSO, it is important to recognize and understand what these different states mean in terms of where your energy will be applied. If you are interviewing or hiring into a company, it is critically important to understand what state the security program is in so you can determine if the opportunity is right for you and to ultimately maximize your impact in the role.

The Different States

In general, a security program can be in one of three different states:

  • New / Building
  • Existing / Incremental
  • Shrinking / Decline

New / Building

A security program that is new typically comes along with new companies, startups or possibly new business units that are acquired via acquisition. However, a company may also be establishing a new program if they are found deficient during an audit or if they suffered a security breach. In this state the CSO (or security leader) needs to establish a program from scratch, which will include mapping risks, developing a budget and establishing funding, recommending tools, evangelizing security best practices and hiring a team. There will be a lot of focus on foundational aspects of security like asset inventory, reporting and initial risk baselines for the organization. Your team will also go after initial program certifications like ISO27001, SOC or other compliance activities. You may even need to establish new processes and ways of working.

Here are some good questions to ask to determine if a program is in the new / building state:

  • Who is performing the function of security today?
  • What goals does the organization have in the first year and three years from now?
  • What is the expected annual budget?
  • How many headcount do you expect for the security team in the first year?
  • Where does your company operate and do you expect to have security resources in those geographic regions?
  • What security tooling is in place today (if any)?
  • Does the company have any existing compliance certifications (like SOC, ISO, etc.)?
  • Why is the company focusing on hiring a security leader and building a security program? Did this come about due to a security incident or other security event like a failed audit?
  • What industries does the company do business in? E.g. finance, government, healthcare, etc.

In my experience, establishing a new security program from scratch is a rare opportunity, but if you get the chance it is truly exciting and offers the opportunity for giant leaps forward in terms of security maturity for the company.

Existing / Incremental

The next state of maturity is existing or incremental and most companies will be in this state. In this state a security program has already been established and has the foundations in place in terms of people, processes and technology. Tooling has already been purchased and implemented, an annual budget has been established and a team exists with different functions like security engineering, security operations and security compliance.

An existing security program usually has smaller goals or incremental annual objectives designed to address some specific area of risk that has been outstanding, or to address a new risk area based on business growth. For example, perhaps the organization has an existing Identity and Access Management (IAM) program, but needs to roll out 2-Factor Authentication (2FA) to further secure access. Or, maybe the business is expanding into the financial industry and needs to become PCI-DSS compliant. These are incremental improvements to the security program and will require increases or reallocation of people and budgets.

A CSO or security leader in charge of an existing security program will generally keep things running smoothly, make sure the company doesn’t regress with respect to security maturity and will continually be evaluating the business for new or existing risks that need to be managed.

Here are some questions you can ask if you are interviewing for a new role that will lead an existing security program:

  • What is the annual budget for the security program?
  • What security tools are in place?
  • How is the team structured?
  • What are the security objectives for this year? For three years?
  • What security compliance certifications does the company maintain (e.g. SOC, ISO, etc.)?
  • How many people are in the security team?
  • What functions does the security team perform? (I.e. security engineering, compliance, risk, product security, security architecture, security operations and incident response, etc.)
  • Why are you looking for hire for this role or who am I replacing if I am hired?
  • How do you expect the business to perform over the next year?

Shrinking / Decline

It is an unfortunate reality that not all programs are in the building or existing states. Sometimes security programs shrink or slip into decline. This can be for a number of reasons such as poor leadership or a declining business. A shrinking security program can also be a temporary state that matches normal expansion / contraction of a mature business and the economy. Whatever the reason, leading a declining security program has significant challenges. First, the security leader will need to over communicate the existing risks to the business and make sure budget and headcount reductions match the reduction of risk as the business shrinks. A CSO can run into real trouble if the reductions are arbitrary and leave the business exposed.

Second, you can expect to have to do more with less. As the business contracts your team will still need to perform, but there may not be additional perks such as training, travel, new tooling, etc. You may also need to consider shrinking budgets and reductions in license counts or other tooling.

Another reason for a shrinking / declining security program is during mergers and acquisitions. Depending on how the deal is structured and the capabilities of the acquiring business, your security team may be redundant or parts of your team may no longer be needed.

A shrinking / declining security program isn’t the end of the world, but it does require careful leadership to make sure the risks are managed appropriately and morale doesn’t completely decline and impact the performance of the remaining team.

Not Everyone Is Good In All States

Not everyone will admit it, but the reality is not everyone is good in all states. This shouldn’t be surprising. Startup founders routinely find they can’t scale a company past a certain point and require additional help. Similarly, I have personally experienced that security programs require different leadership depending on the state of the program and the skills of the individual. Some people just can’t scale a program past the building phase and into the incremental phase. Some people don’t know how to handle decline. Leadership skills aside, some people just have a specific preference for what they like to do.

No matter where you are in your professional career or whatever state your security program is in, I hope this post will help you identify and navigate the type of security program you enjoy leading or are looking to lead one day.

Why Veterans Make Great Security Team Members

Every year the United States honors its fallen service members during Memorial Day. As a Navy Veteran, I spent this past memorial day reflecting on my time in service, the memories I’ve taken away and most importantly remembering the people I served with who made the ultimate sacrifice.

I also thought about the incredible number of people that work for me and with me who are veterans. In general, the veterans I have led, worked next to or served under tended to be the best employees, peers or leaders over the course of my career. Here is why I think veterans make great security team members.

Candor

Anyone who has served in the military or had a military family member knows people who have served tell it like it is. This is a carry over from giving and receiving orders in times of stress that need to be clear and concise. It is also a firm belief that life is too short and at some point you need to stop talking and take action.

Veterans aren’t afraid speak up in times of uncertainty because when we were in the military confusion could lead to loss of life. It is better to ask the question and be really clear than to keep quiet and risk disaster.

This candor is particularly important in a security team. Is there a weakness the business doesn’t know about? Are you seeing something anomalous that other people have dismissed? Do you have a new idea that could improve a process or reduce risk to the business? Veterans aren’t afraid to speak up when they have something to say.

Perseverence

No matter what branch of service you come from, all veteran’s made it through some level of training that was more difficult than the civilian life they left behind. Sleep deprivation, physical hardship and generally being uncomfortable are table stakes in the military. This means veterans are hardened against failure and generally hate to lose. They will persevere through difficult tasks and can be relied upon when things become chaotic and difficult. They also seek out training to better themselves and add new skills to their repertoire because they may come in handy in the future.

This perseverance is particularly useful in all aspects of security. Attempting to change a culture to a security first mindset requires incredible perseverance. Similarly, implementing new controls, resolving an incident or passing an audit also requires perseverance. I’ve found the veterans on my team take these events in stride and enter them with the confidence they will accomplish their task.

Perspective

Veterans also possess a unique perspective. This perspective comes from the hardship they endured during the military and carries over to civilian life. No matter how bad the situation gets every veteran thinks back to a time that was worse in the military and says “hey, this isn’t that bad!” Civilian life can be stressful and I’ve certainly had my share of burnout, breakdowns and disillusionment, but every time I think back to my time in the Navy and am thankful I’m not deployed away from my family, I’m not getting shot at and I’m not being asked to do things that could put me in harms way.

This perspective is useful during security incidents, but can also be useful during every day routine engagements with the rest of the business. Security isn’t always going to go perfectly and sometimes this perspective can help you see the big picture, keep calm and work towards a solution.

Willing To Take Risks

It shouldn’t be surprising that veterans are willing to take risks. Everyone who has served took a huge risk by leaving their civilian safety net behind. We deployed to dangerous parts of the world in order to protect our country. Additionally, veterans will tell you they served because of the camaraderie of the people who sat to their left and right. We are willing to take huge personal risk to protect our fellow service members.

This risk taking attitude is useful in the security space because it lets us try new things. We aren’t afraid to fail because we know we will learn from the experience and can try again. We are also willing to put ourselves out there if we know it will result in a better security posture or reduce risk to the business.

Security Mindset

I’ll generalize here, but I think veterans inherently possess a security mindset. We are evaluating strengths and weaknesses of attackers. We are looking at the physical security of spaces. We are considering if a control is good enough to manage the risk or if we need to push harder to secure something. Serving in the military means serving in an organization whose sole purpose is to ensure the security of the nation it protects. This mindset exists at all levels and is readily transferable to the civilian sector.

This shouldn’t be surprising since a large number of veterans often pursue a post military career in law enforcement, the government sector or private security. However, I also find tons of veterans in the IT sector and particularly in the security space. We have a common mentality and it is usually very easy to spot someone else who has served.

Wrapping Up

If you find yourself lucky enough to lead or work with veterans, like I do, then I encourage you to take some time to explore their background and what they did in the military. I’ve often found swapping stories with another veteran is a quick way to build rapport. Their candor, perseverance, perspective and security mindset can be huge assets to your security team and your business.

Centralized vs. De-Centralized Security Team?

Whether you are building a security team from scratch, expanding your team or re-allocating resources, you may be wondering what is more effective – a centralized or decentralized security team? Both have their pros and cons and I’ll discuss them and my experience with each in this blog post.

Centralized Security Team

This is probably the most common structure for a security team. In most organizations it makes sense to group all people doing the same thing into a single org. Sales people, IT, Finance, HR, etc. all get grouped into a single org with an executive leader at the top. For the security team it has some distinct advantages.

First, the CISO has direct control over the resources in their org. The reality is, whoever is responsible for the performance reviews and paycheck for the resource, is the one who actually controls that resource. This may sound obvious, but I have seen a lot of weird matrixed, resource sharing organization structures that quite frankly don’t work. There can only be one leader and centralizing the security resources under a single security org provides direct control of how those resources will be used.

Second, it provides a single point of contact or “front door concept” for the rest of the business. If there is an incident, security question, customer inquiry, etc. everyone knows who to reach out to and who the leader is for the security group. This can allow the CISO to more easily track metrics, measure risk and dynamically adjust priorities based on the needs of the business.

However, the downside of a centralized security organization is it often gives the impression that the rest of the business is absolved of their responsibility for security. I have heard the following from various parts of the rest of the business:

Why isn’t security doing that?

What is security doing if I have to do it?

What are you doing with all those resources?

A centralized security team can exacerbate the confusion about who is ultimately responsible and accountable for security within the organization. Or, the security team is held accountable for the security failings of the rest of the business even though they aren’t responsible for doing the things that will make the business more secure. These shortcomings can be overcome with a strong security first culture and when the CISO has strong relationships with the other business leaders in the org.

De-Centralized Security Team

A de-centralized security team can improve on some of the short comings of a centralized security team, but it also has disadvantages.

First, a de-centralized security team allows the business to place resources close to and often within the team that is actually responsible for doing the thing. Think about fixing software vulnerabilities. If the development team building the software product has security expertise on their team, that resource can help prioritize and even fix some of the issues as part of an embedded team member. They can raise the security performance of the whole team. This can be an efficient way to deploy resources on a limited budget.

A de-centralized security team can also spread the cost of security around the org in an equitable way. If each function is required to embed a few security resources then those resources (and headcount) are allocated to that business function.

The downside of a de-centralized team is loss of control. The CISO may still be held accountable for the security of the business, but they may not control the headcount budget for these embedded resources. If the CISO is able to hold onto the headcount budget, that is great, but it doesn’t prevent another issue – having the resources go native.

In my experience, de-centralized teams can often go native. This means the resource fails to prioritize the security asks of the team, fail to hold the team accountable or simply start doing non-security work when asked to do so by the rest of the team. If the CISO doesn’t control the headcount then this is effectively a lost (or non) security resource. Even if they do control the headcount, they may have to constantly battle and remind the embedded resources to prioritize security work. This is a particularly glaring problem when there is a weak security culture within the rest of the business.

What Should I Choose?

There really is no right answer here, but if I had to choose one over the other I would choose to centralize the security team and then spend a large amount of time with the rest of the org to articulate their responsibility for security. In an ideal world, that has a large enough headcount budget, I would choose both. Keep a core centralized team like incident response and GRC, but de-centralize application security engineers and architects within the teams that do development work. The structure of a centralized team and even a de-centralized team will be highly dependent on the needs of the business and who is ultimately responsible security.

However, the reality is your organization probably grew organically with the rest of the company and at some point you may be wondering if your organization structure is best to support the rest of the business. Shifting from centralized to de-centralized (or vice versa) is not impossible, but will require careful thought on how to deploy and control the resources so they can be effective. My suggestion is to start small, experiment and see what works for your org.