Organization – Page 2 – 370 Security Blog

Defining Your Security Front Door

A key skill for any security program is to partner with and enable the business to be successful. CISOs need to ensure their security teams are approachable, reasonable and most importantly balancing the needs of the business against potential security risks. While security teams exist to help protect the business, they don’t own the business systems or processes and as a result need to adopt an advisory or consultative role with the rest of the business to ensure success.

With that in mind, the way the rest of the business finds and engages with the security team can create a good first impression or can set the tone for a difficult interaction. Think of a house that has great curb appeal – it feels inviting and gives the impression that the owners take good care of their property. The same concept exists for the security program, which I call the Security Front Door.

The Front Door Concept

The security front door defines how the rest of the business engages with and interacts with the security team. The front door can be a confluence page, slack channel with pinned information, or some place that is easily discoverable and accessible. Your security front door should clearly lay out information and resources so the rest of the business can either self serve or easily request and receive help when needed.

What Should Be In Your Front Door?

The front door for your security program should include ways to perform the most commonly requested actions from the security team. For example, you probably want really clear ways to request the following:

Report an incident
Request vulnerability remediation help
Request an exception
Request an architectural review
Dashboards
Discover documentation for policies and processes
Other – a general way to request help for anything else

The front door is not just a way to make a good first impression and enable the business, but when set up correctly it can actually offload the security team and help the business move faster.

Wrapping Up

The front door is a great way to engage with the business to help them move faster, find information and request assistance from the security team. When done correctly it can allow the rest of the business to self serve and can actually offload the security team by reducing the volume of requests that come in. Setting up the security front door may require a lot of up front work, but by understanding the rest of the business, their key pain points and most commonly requested security asks, you can design a front door that will be a win-win for everyone.

Annual Planning For CISOs

The beginning of the year is a popular time for making personal resolutions, which can focus on health, finance or love. While the beginning of the year is a popular time to set resolutions, really what we are talking about is setting goals to improve ourselves. I’m a huge proponent of setting personal goals for the year because it gives focus and purpose to your actions. The beginning of the year is also a great time to review the annual goals of your security program to set your focus and establish priorities. Annual planning has several objectives that CISOs need to consider and include in their process and I’ll cover them in the rest of this post.

Strategic Planning (Strat Planning)

Strategic, or “strat” planning as it is sometimes called, looks at where the business and your organization want to be over a long term time period. Something like 18 months to 5 years is typical in strat planning. The planning session should include discussion of the one or more of the following macro level business topics:

Market forces and opportunities
Industry trends
Regulatory and legal landscape
Competition
Customer sentiment, goals, etc.
Economic and financial environment
Geo-political climate
Technology trends and latest research

This discussion could be part of a SWOT analysis (Strengths, Weaknesses, Opportunities, Threats), but the goal is to understand where your business is and where you want it to go in the long term.

Align The Security Program

Once the business has a strategic plan, the CISO should conduct a similar planning exercise for where they want the security program to be. These are sometimes called “North Stars”, but they are essentially high level objectives over the long term that merge technology trends, regulatory requirements and security goals into long term objective. These won’t be very specific, but instead should act as guidance for where your team should focus and hopefully end up over the next few years.

Examples

An example of a strategic trend and security objective are as follows:

Trend: As companies shift from the datacenter to the cloud and bring your own device (BYOD), the concept of a traditional perimeter no longer makes sense.

Strategic Security Objective: Shift to a zero trust strategy where identity becomes the perimeter.

The goal is to choose big ticket objectives that will take multiple years to achieve, but will provide guidance to your org and the rest of the business about the direction your team is taking. Your strategic plan will inform the next section, which is your operational plan.

Operational Planning (Op Planning)

Operational planning is more tactical in nature and covers a shorter time period than strategic planning. Op planning usually follows either a fiscal or calendar year that way it aligns to performance reviews and budgeting cycles. In op planning the CISO will select the high level goals they want the security organization to complete that year. Usually op planning will include discussion and planning of the following:

Budget creation, forecasting and changes
Headcount planning
Technology investments (if any)
Top risks to focus on
Any audits or compliance certifications needed that year
Development of timing and roadmap for completing specific projects and tasks
Discussion of security controls and services
Skill gaps and training requirements

The point is to create a tactical plan for the year that will inform your team’s specific goals and objectives. These goals should be clear and measurable. I typically use an iterative approach to break my goals down to my directs and then they break their goals down to their teams and so on. This ensures alignment throughout the business.

Measuring and Adjusting

One important aspect of any plan is to continually measure progress and adjust if needed. Goals and objectives aren’t useful if the business has shifted and they are no longer relevant or have become un-obtainable.

Wrapping Up

Strategic and operational planning are important activities for every CISO. These plans define the long term vision for the security organization and break down that vision into tactical objectives that are accomplished throughout the year. This post discussed a high level overview of what goes into strategic and operational planning, but aligning security plans to business risk, mapping security controls, obtaining funding and reporting progress are all complex activities that every CISO needs to master.

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?

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.

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.

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.

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.

Should Compensation Be Tied To Security Performance?

Lately, I’ve been thinking about how to incentivize security performance across an organization that struggles with the discipline for good security. When done correctly, security can actually help accelerate development lifecycles and is strongly tied to increased organization performance. However, for organizations that struggle, I wonder if they can reward good security behavior with some type of compensation?

CISO compensation is already tied to the security performance of the organization. The success of the security organization to deliver on security goals are already tied to annual KPIs or other performance metrics that tie back to how the CISO is reviewed and ultimately compensated. However, these goals become more risky and less achievable when the CISO is held accountable for security goals across the entire org. The reason for this is the CISO typically doesn’t own the products, systems, applications, etc. that run the underlying business. Instead, the CISO needs to manage the risk for these things and it may often be the case that the CISO or the business will need to make tradeoffs that could be sub-optimal. This could result in the CISO failing to achieve security goals across the org if the rest of the org isn’t held equally accountable.

In an ideal scenario, the rest of the C-Suite will also carry some sort of annual security goal(s) as part of their KPIs. This will effectively tie the performance and compensation of these leaders (CEO, CTO, CFO, CIO, etc.) to how well they deliver on the security goals that are set in agreement with the CISO. If the organization uses cascading goals or KPIs this means the entire org will have some part of their performance compensation tied to how well they execute their security objectives. I can guarantee an engineering team will never skip a security patch again if they are told they won’t get their annual bonus because they missed their annual security goal by shipping a product with a critical security vulnerability.

I also think organizations can gamify and incentivize compensation for security performance even further than just annual performance and compensation. Establishing an internal bug bounty program that rewards employees who find legitimate security issues or rewards teams who never deploy with a critical vulnerability can really accelerate a security program. The challenge for this is it costs money and needs to be balanced with normal business operations. However, I argue paying the people in your org to accelerate security performance will ultimately cost less than the cost of a security breach.

I personally would like to see an organization take security serious enough where they hold the other C-Suite executives accountable for security by tying their compensation to the security performance of their orgs. By bringing this issue to the forefront people will immediately see the real effects of security performance in their paychecks and they won’t be able to ignore the conversation any longer.

Here are the things I think should be part of an organization wide security performance program:

Meeting established security Service Level Objectives (SLOs) for patching
Meeting incident recovery or remediation SLOs
Deploying any type of infrastructure (OS, network, storage, etc.) without critical or high vulnerabilities
Deploying or shipping products and applications without critical or high vulnerabilities
Meeting SLOs for resolution of critical security findings from security researchers or external bug bounty programs
Resolving security risks discovered and documented during mergers and acquisitions within a set time frame (e.g. 1 year or less)
Requiring other C-Suite executives to carry a security performance goal for their organization that is tied to their compensation (same with their org)
Establishing and compensating employees via an internal bug bounty / security issue disclosure program
Closing security exceptions on time or before the due date
Achieving all security audit requirements (e.g. FedRAMP, SOC, ISO, etc.)
Having the entire organization go a set time frame without a phishing incident or BEC

This isn’t an exhaustive list, but I think you get the idea. Organizations should start structuring performance and compensation goals to help the security org and ultimately hold the rest of the business accountable for the security performance of the things they own. This can help remove the adversarial relationship that often develops between security and other groups and push security into the forefront of the decision making process for the rest of the business.

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.