Month: January 2023

Building A Security Budget To Address Risk

Over the past 9 months layoffs have been impacting the tech industry amid heightened concern over the economy, increased scrutiny on profits and over investment by companies in areas that don’t positively impact the bottom line.

As organizations tighten their belts it is possible they will look at the security organization with increased scrutiny and whether you need all of those people, tools or other line items in your budget. As the CISO you may be asked to justify your budget and explain how your budget links back to value or reduced risk for the company. You also need to avoid common budgeting traps like getting forced into a percentage or flat allocation. Here is my approach to this exercise.

Consider The Priorities Of The Business

First, review the immediate priorities from your strategic plan, regulatory and compliance obligations and top risks for the company. Are those still the right things to focus on? Did the development org drop a product or service area that no longer requires the security team to monitor or protect? Has there been a reduction in non-technical staff that may reduce the number of people that need security awareness or phishing training? Has your company abandoned investment in a particular business vertical, which means you no longer need to plan to complete a compliance audit or certification (like FedRamp or PCI-DSS)? Is your company planning to launch a new product, complete a merger & acquisition or expand in a new geographic region? Is there a new emerging threat to your business that needs attention?

Ultimately, the answers to these questions will result in a few possibilities:

  1. The business is going to continue to grow and invest, which will require the security team to also grow and invest so the business can mitigate or reduce new risk.
  2. The business will maintain existing investment and exposure to risk, but not increase it.
  3. The business will reduce investment based on contraction of business areas that will result in reduced risk to the business.

Articulate A Plan To Address Business Risk

Second, the CISO’s job is to articulate risk and present recommendations to the business for how to address the risk. However, it is important to remember that the business may choose not to follow your recommendations and that’s ok. A CISO should have strong relationships with the other C-Suite executives, but they also need strong relationships with the various corporate functions like legal, HR and finance.

Whether your company is growing, staying the same or contracting, the CISO still needs to present an appropriate budget recommendation and plan to address the risks to the business. I’ve covered how to build a strategic plan before and that should be one of the primary inputs to this exercise.

Planning For Headcount To Reduce Risk

Generally, when considering people resources you should plan to have at least two years of work for those people to accomplish. This means you should look at your strategic plan and consider what risks you can address with the existing resources in your organization over the next two years. Map people to projects with realistic timelines, deliverables and deadlines. Link the priorities back to the strategic plan.

Next, consider what additional risks you could address if you could add additional people to your organization. Are they completing a new compliance audit like ISO27001? Are they implementing a new tool or developing a new process to address an unaddressed risk (such as SBOM or API security)? Do you need additional resources for your SOC to improve chase the sun coverage or to have redundancy when people are on vacation or sick? Is there a particular geographic region that needs investment or that offers similar talent to premium locations, but is currently less expensive? Remember it takes time to identify, hire and train new talent before they are productive.

Lastly, consider what would happen to your plan if people left the organization. Can you still accomplish your goals if you have 5% attrition, 10%, 20% or more? Will it simply take longer to reduce the risk or does less resources make the objective impossible and so now the business will now be exposed? Conduct succession planning to fill the immediate gaps and then build in contingencies in your budget to hire or backfill if needed.

Planning For Technology To Reduce Risk

Taking it one step further, consider what new tooling investments you need to make to address the top risks in your strategic plan. Do you need a new SIEM? Do you need a SAST/DAST scanning capability? Do you need better endpoint detection and response (EDR)? Can you free up people resources by implementing a new tool or automating a process? Determine the best tool and get budgetary pricing for your budget. Depending on how tightly your finance org runs the budget you may also want to add in a tooling contingency to allow the org to pivot or add something new part way through the fiscal year.

Other Budgetary Considerations

Depending on the remit of your security org you may or may not have other line items in your budget. Below are some examples:

  • Penetration tests conducted by an external company
  • Physical security improvements like cameras, alarms, badge readers, safes, etc.
  • Compliance Audits (SOC, ISO, FedRAMP, etc.) or other audits and certifications by external firms
  • Contractors or professional services for short term (1 year or less) engagements
  • MSSP or service providers if you outsource parts of your security org (like incident response)
  • BugBounties for external security researchers
  • Cyber Insurance (with planned increase if you are entering new business areas)
  • Possible legal fees for lawsuits, contractual reviews, outside counsel or other security related legal matters depending on how finance allocates these costs in the overall budget
  • Lab, subscription and equipment costs for threat hunting, security research, cyber ranges or training exercises
  • Executive protection costs for your C-Suite executives
  • Brand and reputation monitoring
  • Training costs for conferences, certifications, tuition reimbursement, security awareness, phishing exercises or other training and education related fees
  • Costs for maintaining specialized security functions like a SCIF, holding clearances, renewing clearances, liaising with law enforcement or other federal agencies
  • Costs for participating in security trade groups, boards or other industry facing security groups that help influence activities for your business
  • Outside consulting firms for specific areas of expertise and unique circumstances like VIP security protection or protecting large events (like company conferences or other extremely large events)

Security Isn’t Just A Cost Center

Don’t forget to offset your budget with activities that positively impact the bottom line for the business. Depending on how your organization is structured you may have customer and industry facing groups or groups that participate in activities like Mergers & Acquisitions. If you have Security Consultants, Professional Services, offer Managed Security Services or participate in other activities that positively impact the bottom line, then your org should get credit for these activities and they should help offset the other security budget items that are typically a cost center for the business. You can have your go to market team or customer facing security resources tag activities in your CRM tool and then pull reports based on this tag. You can also do this with a simple spreadsheet that captures the date, the dollar amount, how many security folks were involved and a short description of the activity. This can be really powerful to show how the security org is helping to not only protect the business, but directly or indirectly improve the bottom line.

Final Thoughts

A lot goes into creating a budget for your security organization with the ultimate goal of reducing or mitigating risk to the business. It is easy to fall into a trap of simply looking at the security org as a percentage of overall headcount for the rest of the business and then allocating budget accordingly. There are metrics floating around the internet claiming security budgets are on average some percentage of the IT budget, or some other percentage of the overall technology spend for an organization. This is the wrong approach in my opinion.

Allocating a flat percentage can result in underinvestment in the security org, which means risk to the business will tacitly (or explicitly) go unaddressed. Having a strong relationship with the finance org and linking your budget requests back to your security organization plan and strategic security plan is the best way to plan and execute a budget that is grounded in reality to reduce risk instead of using arbitrary percentages.

The finance org can also help to make sure you are following their accounting process such as spreading costs over quarters, not recognizing costs until the quarter you actually have to start paying for something, reminding the security org when renewals are coming up and making sure you are sent reminders for when accounting is going to reclaim allocated budget if you don’t spend it in time. They can also help you move things around within the fiscal year so you can maintain your budget based on shifting priorities.

Lastly, I encourage all CISOs to have a budgetary dispute resolution process facilitated by finance and decided on by either the rest of the C-Suite or the board. CISOs need to be able to raise critical risks in terms of staffing, tooling or other issues that will ultimately impact the budget and is separate from the normal budget process. This isn’t a blank check, but a process to break through during urgent situations (like breaches or incidents) and get the budget needed to quickly resolve the issue.

Building a budget for the security org is a time consuming, but critical process. CISOs need to be grounded in basic finance and understand the true P&L of the security function so they can accurately articulate value as related to risk management. The finance org is your greatest ally to assist you with this process to make sure you are putting things in the right buckets (Opex vs Capex). While finance may have rigid processes for how they want to plan for the budget, it is up to the CISO to link their budget back to a strategic plan to address risk for the business and present that plan for approval without falling into traps of percentages or flat allocations.

How Will The CSO Role Change Post Uber?

I had a really interesting discussion with some CISO friends last week about how the CSO/CISO role will change after the guilty verdict of Uber CISO Joe Sullivan (I’ll refer to this as the Uber verdict going forward). Here are my personal thoughts:

The Scope of Liability Has Changed

The Uber verdict has now set the precedent that a CSO can be held personally liable for security failures at an organization. This means data breaches, security incidents, regulatory and compliance audits, external inquiries and bug bounties all carry increased weight for them to be handled appropriately according laws, industry regulations, corporate policies and ultimately how you handled the event should it end up in court.

The Uber verdict also demonstrated that there is a limitation to how much coverage and protection a company will provide to a CSO / CISO after major security events have occurred.

While this may sound ominous and extremely concerning, I don’t think it should be. Ultimately, if you aren’t breaking the law, have a well defined security plan and are documenting your progress I don’t think you need to do anything different as a result of this verdict.

Negotiate For Protections

While you may not need to do anything differently with respect to your security program, I do think it will become industry standard for CSOs to negotiate protections as part of an employment contract. Prospective company’s should plan to add CSOs to their corporate liability coverage for executives and can also expect existing executives or prospective candidates to push for written assurances that they will be covered legally and will not be sued by their employer.

The Role Will Be Elevated

Ultimately, all of this will result in elevating the CSO role to be on par with other C-Level positions such as the CEO, CFO and even Chief Counsel who all carry significant levels of risk in their positions. The security industry and ultimately the CSO role are relatively young compared to other C-Level positions and so I think the Uber verdict will give the role a hefty shove forward and help it find equal footing with some of the other more tenured C-Level positions.

In the end this means companies will begin taking the role more seriously as they are forced to add the role to their corporate liability policy, provide legal protections as part of employment contracts and begin offering the same level of weight to the CSO role as they do to other C-Level roles.

Ultimately This Is A Good Thing

While it may sound concerning that a CISO was held personally liable for a security event at a public company I think this is the exception, not the norm. The circumstances of this particular verdict clearly demonstrated non-standard behavior and a good example of what not to do when dealing with federal investigators.

However, I do think it has caused a certain amount of pause and reflection within the CSO / CISO community. CSOs are now beginning to consider if their programs are sufficient to stand up to external scrutiny and they are asking what they need to do to protect themselves going forward. This will result in existing or new candidates asking for protections, which will eventually become standard. As the protections become standard it will cause companies to take the role more seriously and ultimately give it the same weight as other high risk C-Level positions.

Legal Privilege

Disclaimer

First I want to start out by saying I am not a lawyer and I don’t play one on TV. This blog post is a summation of legal advice I have been given over the course of my career as a CSO/CISO. These are my opinions and should not be considered legal advice. If you need legal advice seek out a lawyer within your company or your professional network. Legal advice will differ based on your company’s risk profile, your lawyer’s background and experience, the specific situation, what geographic regions your company operates in and the industry you are in. I highly recommend you and your team have regular briefings from your legal department to refresh the concept of legal privilege and any other legal concepts they think are important.

Ok, with that out of the way let’s dive in.

What is legal privilege?

Legal privilege is a form of protected communication between you and a lawyer for forms of recorded communication (like email). Specifically, this communication needs to seek or convey advice from the lawyer. For example:

“Dear Lawyer, I need legal advice about the following…”

Why Is Legal Privilege Important?

When seeking legal advice, legal privilege protects the communication from legal discovery. This means if your company is sued and you go to court these communications about this legal advice can’t be used as evidence. It also gives you an option to use a form of recorded communication and invoking legal privilege so that communication is on record, or using an alternate, non recorded form of communication so the communication is not on record. This is a really important concept for a CSO to understand and a tool to use to protect themselves, their team and ultimately the company. By invoking legal privilege for key conversations, that are discoverable, you can ensure those conversations will be protected from a legal standpoint.

How Do I Invoke Legal Privilege?

Generally, legal privilege can be invoked by you to a lawyer, or by a lawyer to you. The exact details of how to do this may vary depending on your company, your legal counsel, etc. but here are a few ways to invoke legal privilege via email.

  • Include the lawyer in the To: line
  • Keep the audience to an absolute minimum
  • Header and Body should include the word PRIVILEGED at the start (or some other indicator specified by your counsel)

How Do I Include Other People In The Legal Privilege?

If you need to include other people in the email (like your management chain), then ask your legal counsel to include them. If someone gets added that shouldn’t be on the thread, ask the lawyers to remove them from the thread. If someone claims they need to be included, forward their claim to the lawyers to evaluate if they truly need to be on the thread or not. The wider the audience, the more difficult it is to claim legal privilege and it is even possible to lose legal privilege.

Can I Lose Legal Privilege Once It Is Invoked?

Yes, if the email thread is distributed to a larger audience than needed this can cause you to lose legal privilege. For example, if you are discussing a security incident with your lawyers and someone unnecessarily copies an email distro to the thread this can cause you to lose privilege. This means all of the emails will now be discoverable.

Are There Other Circumstances Where I Am Not Protected?

This should be a no brainer, but you are not protected from legal privilege if you are participating in crime or fraud.

You are also not protected from legal privilege if you don’t invoke it. This means non-privileged documents are not protected just because they are in the possession of a lawyer.

Is Legal Privilege The Same Everywhere?

No. Legal privilege differs by country. The bar for establishing and maintaining legal privilege can be much higher in some countries, than in others. If you are part of a global company, I recommend you get briefings from lawyers that are familiar with the laws in the countries where your company does business.

Examples Of When To Use Legal Privilege

First off, I just want to say legal privilege does not mean you should copy your legal counsel on every email. Legal privilege is not designed to protect all your emails / communications. It is only designed to protect advice between you and a lawyer. That being said if you are communicating with a lawyer it is a good idea to always invoke legal privilege that way it is protected.

Here are some examples of when to invoke legal privilege:

Discussing A Security Incident

“Dear Lawyer, please advise what course of action we should take due to this incident…”

This is probable the most common way a CSO will use legal privilege. Discussing an active incident, customers impacted, legal ramifications, etc. should all be done under legal privilege between you and your legal counsel.

Changes To Industry Regulations

“Dear Lawyer, please advise how our company should adjust to this new industry regulation…”

I recommend seeking the advice of and invoking legal privilege for changes to industry regulations. I recommend this because the interpretation of the change may indicate your company is not compliant or is going to take some other course of action.

Disclosing Information To Customers

“Dear Lawyer, I am unsure how to respond to this customer, please advise…”

Transparency should always be the goal, but sometimes there are things that shouldn’t be disclosed externally. When a customer makes a request for a new piece of information I recommend seeking the advice of your legal counsel about how to respond and then standardize that response for other customers. Sometimes the response will be – “we don’t provide that information externally”. Or, the response may be a limited set of the information requested. It will all depend on what your legal counsel recommends based on the risk publicly disclosing the information presents to your company.

Legal privilege is a complex area to navigate, but one that is an essential for every CSO to have in their toolbox. Understanding when to invoke it, how to invoke it and how to maintain it is essential for success in the role. The legal department is an essential partner for any CSO and their organization. I recommend building a relationship with them and having legal help you work through scenarios where legal privilege is needed. When in doubt, I recommend explicitly invoking privilege between you and your lawyer.

Giving A Presentation To The Board

At some point in your CSO / CISO career you will need to give an update to the board. This could be monthly, quarterly or yearly depending on the size of your company. Wondering where to start? Here is a template I have found to be successful.

Practice Makes Perfect

If you are new to presenting or are an experienced veteran I highly recommend creating your presentation and then writing down what you are going to say in the speaker notes. Practice the presentation, transitions, etc. until you can do it without reading the slides and so the presentation sounds natural. Record yourself and watch it a few times to catch yourself saying “uh or uhm” and to see what you will look or sound like from the perspective of the audience. Give the presentation to a family member or friend to get their opinion on how to improve. The more you practice the more relaxed and prepared you will be when in front of the board.

Know Your Audience

I often see presenters assume the board knows (or wants to know) specific details about technology, products, services, etc. when presenting. In my experience they don’t. The board are not experts in your day to day operations. They are usually highly compensated executives trying to run large organizations and you are giving them a narrow window into your world. You need to highlight and raise things for them to anchor on or key into so they can orient themselves around making an appropriate decision with the information you presented. I keep technical information in back up slides in case one of the board members wants to go deep, but typically they want to know the following:

How Has Risk To The Business Changed Since You Last Presented?

This section will be a combination of global security trends impacting your industry and the current status of the strategic plan. I like to start out by giving an overview of whether our risk as increased, decreased or stayed the same since the last time. A graph is really helpful here and allows the board to orient their thoughts while you give a short introduction and explanation.

If you are just starting out with the strategic plan then this will focus more heavily on how you are planning to prioritize the security controls in the plan and when the board can expect results.

What Caused This Change In Risk?

Why did risk to the business increase, decrease or stay the same since last time? If risk decreased highlight the controls or process improvements the organization made to achieve this reduction. If risk increased tell the truth and then give your recommendation for how to manage or reduce this risk over a specific time period. This could involve asking for additional funding, personnel or even asking for a particular group, product or service team to focus on a particular area to make progress.

What Are The Top Three Risks To The Business At This Time?

You are the expert and the board wants to hear your opinion on this. These risks probably won’t drastically change between presentations, but I like to remind the board on the risks and then present a suggested plan to manage or reduce these risks in the Look Ahead section.

Metrics For Security Incidents

This is a good section to add metrics on number of security incidents, what caused those incidents, what was the time to resolution, etc. It may also be a good area to give a quick summary on progress with vulnerabilities in production, or maybe the after action results of a specific incident the board wants more information on.

Look Ahead

Lastly, I like to wrap up the presentation with a look ahead about what my team is going to focus on between now and the next board presentation. This could involve implementing new controls or technology to reduce a specific risk area. This is a good place to work in your investment asks. I typically give a list of 3-5 things, what they are, why they are important, what the ask is (if any) and the outcome I’m expecting once the things are completed. I tie these into the top 3 risks to the business and then give a short conclusion before asking if there are questions.

Cultural Change Agent – Part 2 What Does Work?

In Part 1 of this post I discussed how security teams are often challenged to change behavior and ultimately culture. This is an exceptionally difficult problem and I covered a few things that don’t work when trying to effect change. In this post I’ll discuss my observations for what does work when trying to change behavior to a security first mindset.

What Does Work?

Assume Good Intent And Be A Patient Teacher

This one speaks to mindset. When coaching my team I often find they are frustrated with another group unnecessarily. When diving into the problem there is usually a lot of blaming and an us vs. them attitude. There is also an underlying assumption that the team is not doing something because they don’t want to.

Instead, I coach my team to adjust their perspective and lead with empathy. It is exceptionally rare that a team flat out refuses to do something security related. Instead, I find a team wants to do the thing, but just doesn’t know how. Changing your mindset from a negative one (they aren’t doing it) to a positive one (they want to do it, but don’t know how) changes the entire dynamic of the conversation with the other team. Practicing empathy, and ultimately patience, with other teams by coaching them to the outcome you want is far more effective than blaming them for failing to comply.

Make Security Easy (Without Compromising Effectiveness)

I touched on this briefly in Part 1, but I’ll say it again here because it is worth repeating. Humans will take the easy path, follow habit or both. Security teams need to find solutions that make security easy, without compromising effectiveness.

A good example is patching. Make it easy for teams by publishing hardened, up to date images, containers, etc. that they can pull and use for their products / services. Take the burden off of them to have to patch an OS by providing them with a patched version up front. (Yes there is a lot of nuance to this. I’ll discuss this more in a later post).

Enlist Allies

Enlisting allies on other teams can really help accelerate your security goals. Teams within IT, the CTO group and even senior engineers can help get momentum behind key initiatives and act as an extension of the security team.

In my current function we use these allies in the following ways:
  • Early Adopters – New processes and technologies always have issues. Having a team of early adopters outside the security function helps iron out the bugs before trying to get the entire organization to adopt it.
  • Security Champions – In my current function we use our security allies to help champion initiatives or act as an extension of the security team. This is invaluable because it helps explain things in a way that is understood natively by the receiving team and it is delivered by someone within their own group. This can be particularly effective when one team is behind on something (like patching) and needs a little extra encouragement.
  • Extended Vulnerability Response Team – During Log4j we found the security allies to be invaluable in responding to the vulnerability. They were able to take the new patches / fixes and translate that to their products or services. They were also able to come back with suggestions and improvements to processes to speed up remediation. By having key allies represent the engineering groups we were able to keep our War Room relatively small and relied on them to deliver marching orders to their teams so we could tackle the issue at scale.

Set The Example (Lead From The Front)

Sometimes teams need to see what good is before doing it themselves. The CSO / CISO and ultimately the security team should set the example for the type of behavior they want to see from the rest of the organization. This shouldn’t create an us vs. them or sense or superiority, but instead should act as an eat your own dog food type of exercise. If you are asking teams to patch things, then your team should follow the same processes. By participating in the very same processes you are asking the rest of the org to follow it creates accountability for your team to make sure those processes work appropriately.

Trust But Verify

Simple, but effective. Early in my current role I often had teams tell me one thing and I took their word for it. I did this because I simply didn’t have the staff to chase down every little thing and I assumed good intent. As my team matured and we developed better processes for collecting data, we found what people told us didn’t match up to reality. This wasn’t a case of malicious intent, but instead the reality of working in a large organization. Things change, people leave, nothing is static. One of my history professors used to say “the palest ink is better than the fondest memory.” This is true with security data. Talk to people, get their perspective and then go check it out to see if that is true. If it isn’t, then that is an area to focus on.

Like any skill, practice makes perfect. I often find when I am getting frustrated it is because I am slipping back into bad habits like failing to assume good intent or leading with empathy. A simple mindset shift usually snaps me out of it and I spend a large amount of my time reinforcing these principles across my team. I hope you find these skills useful and are able to put them to use in your organization to achieve cultural change.

Cultural Change Agent – Part 1 What Doesn't Work?

When you are hired for a security leadership at a company you are being hired because the company has a need for your experience. The company may need help with reducing risk to a new business area, successfully passing a new compliance audit, implementing a new security capability or simply growing the team to match the growth of the company. All of these are possibilities, but I often find one of the most important underlying reasons a company hires a new security leader is to effect behavioral and cultural change. Changing behavior, and ultimately the culture, of a company is an exceptionally difficult challenge for a security leader and the following are some examples of what doesn’t work when trying to effect change. In Part 2 I’ll cover what does work.

What Doesn’t Work?

First, let’s talk about what doesn’t work. In some cases I have learned these lessons the hard way. In other cases, I’ve learned these lessons through observation or listening to my peers.

Don’t Be The Mafia (Or What I Like To Call “The NO Factory”)

First up, avoid creating an adversarial relationship between your team and the rest of the company. If the security team constantly tells the rest of the company NO, then eventually the rest of the company will start ignoring your team and this will become a problem in terms of risk management, security enforcement, support during incidents, etc.

I find a much better approach is to figure out how to enable the business with security. What does this mean? It means working with the non-security teams to put processes, people or technology in the right places so they are minimally invasive, while achieving the security objectives.

Example – Architectural Review Process:

Several years ago my team was responsible for reviewing new architectures for security issues before they went into production. This was a very lightweight process with two phases – a conceptual review (does this make sense) and then a more detailed post production review (did you do what you said you were going to do). In order to achieve the results of managing or reducing risk appropriately my team ended up acting in a consulting role to work alongside the other teams to help improve their security as part of the Architectural Review Process. We even eventually automated several of the compliance checks and scans to shorten the feedback loop and allow teams to self service as they were building their new thing. The end result was the security team built trust with the rest of the business and we ultimately reduced risk. If, instead, my team told the non-security teams NO every time they submitted something that wasn’t up to security standards, they probably would have just deployed to production anyway without meeting our security requirements and this would have put the company at significant risk.

Don’t Confuse Accountability With Ownership

If you have ever read Extreme Ownership by Jocko Willink then you are familiar with the concept that good leaders should take ownership for everything in their world. In the case of security this would mean the security function should be responsible for patching, hardening, scanning, etc. of everything in the company. Yet, I argue this is not only impossible, but the wrong approach.

Why is this impossible?

The team building the product or service needs to be responsible for the security of that service. If you aren’t the team building the product or service then you may not have the right permissions, you may not understand the code and you may not even know it exists.

Why is it the wrong approach?

Asking another team, other than the one who produced the product, to be responsible for patching, hardening, scanning, etc. of a product or service, passes the responsibility and accountability for security away from the team that actually owns the product or service, which means the original team will have zero incentive to develop a product or service that meets the appropriate security requirements.

As a CSO/CISO you are accountable for the security posture of the company, yet the security function doesn’t actually own the products or services that the company sells to customers. The teams who build the products or services are responsible for patching them, scanning them and fixing the security issues that are discovered in them. The non-security leaders over these teams need to hold their teams accountable for meeting the appropriate security requirements and the CSO/CISO needs to hold these leaders accountable (with things like dashboards, scan results, etc.).

Don’t Underestimate The Human Factor

When beginning a new security leadership position it is usually easy to identify the technological solution to a problem. Need more visibility? Improve logging and alerting. Need to know who owns something? Improve asset inventory. Need to shorten the vulnerability window? Improve patching. However, it is often extremely difficult to diagnose and understand the behavior of the humans who are behind the security problem you are dealing with.

Technology is easy, humans are complex

I often say this to my team to remind them that people are the most valuable asset for a company, but are also the most challenging. It also reminds them to not jump to a technological solution. Spend time talking to people to understand how and why they the things they do so you and your team can develop ways for them to achieve your security goals as quickly and easily as possible.

Changing patterns or behavior within a company or group takes time and is difficult. Humans will do what is easy, what is habit or both, often at the expense of security. Make small changes to processes or technology to gradually nudge teams into compliance.

I hope this helps you avoid these pitfalls so you and your team can be successful in achieving your security objectives via cultural change. Up next – Cultural Change Agent – Part 2 What Does Work?.