The CISO role can be lonely. You need to protect the business while also driving its growth. It’s a world of competing priorities and constrained budgets. And, of course, you’re walking into an environment that may have holes in places you didn’t know exist. I get it, I’ve been there.

Security is not an end-state, it’s a commitment to effective behaviors. This article is not the “Live, Laugh, Love” of CISO advice — we get enough of that. Here are some actionable tips I’ve learned that I hope will help you navigate your first 90 days as a CISO — injected with tips from some of my favorite security executives. I hope this can be a living document, so feel free to ping me with ideas for updates or next versions! 

 

30-day checklist: Listen, learn, assess. And firefight if necessary!

When I first started in AWS’ Office of the CISO, a senior executive in another part of the business said to me, “You are going to do fine; you have two ears and one mouth.” Those of you who know me, know that I am no shrinking violet. But it was a good reminder that while it might be tempting to jump right in, in the first few weeks, it is more powerful to listen. Ask lots of questions before starting any strong measures. You’ll pick up some important information about the organization:

• How things get done (or don’t!) 
• Processes and rituals for interactions (every business I’ve ever worked at claims to be flat; each one was, in fact, pretty hierarchical) 
• Who makes decisions — including budget, hiring, and business priorities
• Real or potential single points of failure, or major processes that hinge on one individual
• Who works well together (and who doesn’t)

Soon, we will start to turn wheels.

Perform an initial assessment (I call this “notes to myself”)

Your fresh eyes are a powerful mechanism for change

You’re probably not best off making huge changes in your first few weeks. But, one tactic I use is to write myself notes to revisit when I have more context, in a few months. In other words, save those “fresh eyes” insights and decide when — and how — to question the status quo, after a few months. Put a calendar invite for yourself on month 4, to revisit your early notes to yourself and decide which “we’ve always done it this way” elements are worth challenging.

Asset inventory is a huge challenge for most shops

Figure out what you have — though I know it’s easier said than done! In practice, this can take the form of some abstraction calls (Amazon Elastic Compute Cloud [EC2] describe calls are your friend) as well as some manual processes like asking for asset descriptions and lists. Remember that even if you’re using a visibility software vendor, you need to ensure the integration is functional (e.g., turn on CloudTrail so you can see every API call).

 

💡 CISO-to-CISO tip: "One of the first priorities is understanding what assets you have across the entire enterprise.  Hardware asset management is absolutely critical to get your arms around as so many other things build on that. It also has to be done in an automated fashion — spreadsheets were never a good method. Once you know what you have from an IT and OT perspective then you can formulate what will be required to maintain your security and risk posture."   

— Tony Parrillo, Schneider Electric VP Global Head of Enterprise IT Cybersecurity

 

Figure out what metrics your counterparts in the organization are using

What is the IT team measured against? Speed to deploy? Clean code? How do initiatives get funded?

Ask: to what metrics will this role be held accountable? What is the security shop doing today? What does success look like, according to the CEO and other leaders? Of course, at some point you will likely circle back and suggest to update these, but for now, find out what is in place.

Ask about any existing codified plans, including compliance reports from previous periods

Review them, but also ask your colleagues about what happens in practice. Everywhere I have worked has some plans written down; many don’t actually use them, or only adhere in part. (It’s better to know the truth than to stick your head in the sand about policy accuracy–your auditors, and possible attackers, will find out soon enough.)

Flag “house on fire” issues that need immediate attention

Ask questions like: 

• Where are the root credentials stored and how are they protected? (hopefully MFA!) Are there workloads running on root? (hopefully not!)
• Who has superadmin access? What’s the process for getting that?
• Are we encrypting by default, data at-rest and in-transit? (this can be easier than ever, with infrastructure as code and use of delegated requirements, not to mention cloud provider defaults for encryption.)
• Have you revoked the permissions of former employees?
• Are there any hard-coded credentials or keys that you need to rotate and/or script for ongoing rotation? (please: use key management systems where possible!)  
• What visibility do we have that would show exfiltration?

Start preparing for regulatory compliance responses

You’ll be responsible for many regulatory compliance responses. Some of these will be industry- or situation-specific, but some of these are table stakes. For example, all public companies are subject to U.S. Securities and Exchange Commission (SEC) regulations; all companies transacting currency in the US are subject to Payment Card Industry (PCI) security standards compliance; many, including financial and healthcare entities, need International Organization for Standardization (ISO) 27001 compliance; all doing business with EU residents are subject to General Data Protection Regulation (GDPR), the UK has its own flavor of GDPR, and so on.

Hit some immediate priorities

Identity, identity, identity

Now it’s time to determine what the business is doing today around access, including third-party apps. Streamline access, set up federation and single sign-on (SSO) wherever possible so your employees find it painless to provision themselves the tools they need and so you have the ability to greenlight the use of particular apps and tools. Organize your cloud access permissions and take advantage of templatization. While it’s an overused buzzword, we should take from “zero trust” what I think of as the core meaning: do not inherently trust an entity (whether human or machine) simply because it got inside the network. What we really mean when we refer to “zero trust” is that you should commit to continuous permissions pruning and implement a mix of perimeter-based and fine-grained, identity-centric controls. Continuous pruning takes work but gives a healthy amount of friction to identity and access controls.

 

💡CISO-to-CISO tip: "Ruthlessly prioritize the most impactful actions an organization must take to advance the company's security posture. It is critical to be pragmatic and not to boil the ocean. When defining goals, include the leaders of the organizations that will need to take actions such as product, engineering, and IT. Work together to determine the goals that strike a balance between what realistically can be accomplished by the organization and the sense of urgency. Based on my experience, defining measurable goals quarterly and having monthly reviews with the cross-functional leadership team is the right cadence for many organizations." 

— Olga Lagunova, Chief Technology Officer, GoTo

 

Implement/refine the trouble ticketing system

I know trouble ticketing is painful, but I don’t know a security team that isn’t captive to one. Trouble ticketing is powerful because it inherently provides authorization/authentication for those submitting tickets (and is much more traceable than email). Ideally, trouble tickets are beneficial in a couple of ways. First, they allow you to track/measure the time to respond and time to resolve. Perhaps even more importantly, they allow you to see which issues are continually popping up and to increasingly allow bots to resolve “known requests” with automation. (Under the hood, these are serverless functions — in AWS, it’s Lambda). In other words, if you know that you will allow for certain exceptions under certain conditions, codify those. Some teams will get permission grants when they submit a trouble ticket, for example. Minimize the “gray area of human decision-making” down so that more and more responses to trouble tickets can be automation-driven.

Ensure you’re training and hiring for engineers that love automation

Let them start codifying away issues that you have made determinations around. As a nice side-bonus, you will retain smart people who dislike doing manual tasks that are better done by computers!

Take these metrics and start to parse them

Which teams are hitting guardrails the most? Why? Is your environment too restrictive, or are they coloring outside the lines?

Do a vendor review

Do a vendor review, just like you did an asset review. Where are you currently spending? What are you getting from the vendors you’re using? When are contracts coming up for renewal? Are there capabilities you’re paying for but not getting from vendors so that you can consolidate?

Make sure there is some kind of incident response mechanism in place

Do you have a pager roster? What is the business’ tolerance for escalation? For example, do pager alerts escalate after 5 minutes or 15 minutes if unacknowledged?

Set starting metrics

Set some starting metrics to follow around response times, remediation times, number of requests, exceptions, and so on. Resist the temptation to gamify these because what you really want to know is if you are getting better over time. 

Build relationships, grow champions

Meet with leaders

Get on calendars for leaders on the legal, finance, product, and HR teams and the CTO, CIO, and CEO. Ask what they care about. Ask what they think hasn’t been working. The IT, legal, and product folks will be especially critical stakeholders for you on substance, and the CEO needs to be aware that you’ll bring business risk determinations to their door.

 

💡 CISO-to-CISO tip: "Having a good relationship with the CIO and other stakeholders is crucial. Security needs to be aligned with the broader business goals, otherwise, you’ll just be spinning your wheels trying to get things done. By building trust with the stakeholders, the CISO can more effectively champion security initiatives and cultivate a security-aware culture within the organization."

   — Jason Thomas, Chief Information Officer and Head of Security, Cole, Scott & Kissane

 

Take a look at the existing security budget with an open mind and a critical eye

Remember that with the cloud and the rise of DevSecOps, your IT and cloud budgets may be more intertwined with the security budget. It’s important to understand the timeline for the next budget planning cycle and ensure you’re prepared.

 

60-day checklist: Strategy formulation and alignment

As you transition into your second month as CISO, you’re ready to get your hands a little more dirty. Take the information you uncovered in the first 30 days and transform it into actionable plans, and start to look at medium- and long-term improvements, too.

Consider automating and consolidating

Budgets are always tight but so many folks are either paying for tooling that is redundant or not provisioned properly, and many aren’t taking advantage of all the capabilities in the tools they have. 

Look at where you can take manual processes that may have been catered to with adding headcount, and turn them into automation and tooling that extracts insights better for you to act upon. This might mean paying for vendor software that allows you to get better signal to noise ratio for alerting (via prioritization of assets correlated with threat intelligence), and to contextualize data, inspect code and container images before they deploy, and so on. (Yes, full disclosure: I work for Lacework, in part because we do this for folks and I know it’s important!)

Before you throw headcount at every problem, ask yourself if you can find ways to get better outcomes without the inherently unscalable element of human judgment.

Patch, patch, patch

Most CISOs inherit a lot of unpatched assets. Start doing the hard work of patching while minimizing possible fall-out. (I know, the longer it has been since you patched, the more likely it is that it really will break something.) To do this, you need to get other business leaders on board that you might cause some outages as you get to a better state.

Get a vision and strategy on paper

Create a longer-term plan

It doesn’t have to be perfect, but work with your team to create a longer term plan and socialize it with the rest of the business.

Start metrics for reporting to the board

There’s no gospel for what exactly to report except for meaningful business outcomes. Start somewhere, and get feedback.

Train and upskill your security team

Start now with cloud security, DevOps, and other training that allows for professional development as well as opportunities for the shop to mature. The main cloud providers (AWS Cloud, Google Cloud, Azure) have lots of free trainings online and there are many labs, on Github and elsewhere, to help your team build their skills. 

Create runbooks and playbooks for incidents

Create a cadence for practicing them (at least quarterly).

 

💡CISO-to-CISO tip: "It’s always best to paint a clear 'Vision, Mission, Objectives' statement to both your team and organization as a whole once you’ve gotten through your initial assessment period. Understand that this vision is not static in nature, but rather should be aspirational enough to motivate your teams and stakeholders to achieve the program that you intend to build. Work from the top and go backwards. Paint a clear picture of what your program’s 'mountain top' of maturity looks like and critically assess where you are now. When you understand where you truly are and where you would like to be, it becomes much easier to map out the steps to getting there."

— George Y. Al-Koura, Chief Information Security Officer, Ruby Life Ltd. 

 

Create your immutable and ephemeral environment templates

Make it easy to get back to a known good state

If you are in the cloud (and you should be!), you should take advantage of the ability to vend identities, vend environments, do immutable backups and get back to a known good state, whether that’s an environment or an Amazon Machine Image (AMI). This will take the form of things like templatization for spinning up environments (e.g, Terraform, CloudFormation) as well as using organizational structures like AWS Organizations and delegating permissions. Minimize “snowflake” environments because paved roads are the best way for the security team to keep arms around employee activities. Plan for immutable backup and redundancy and make it easy to get back to a known good state. This might take the form of a golden AMI, cloning your databases, or using Write Once Read Many (WORM) storage for backups.

Use lifecycle management for your backups

Coordinate with Legal and decide what your timeline for data retention will be (some of these are regulated requiremetns, some are business decisions). Run these business decisions past your CEO and other business stakeholders to ensure they are on board with your judgment calls. As a fun bonus, you’ll save a little money by deleting unnecessary resources, as you also minimize exposure of holding onto unnecessary data.

Take advantage of canaries to know you’ve done what you think you’ve done

Canaries ensure you’ve implemented the controls you intended. Some canaries should always fail, some should always go through. In cloud you can also reason about your permissions before you ever deploy, and reason about network reachability without ever sending a packet over the network.

Create an appsec process

Create an appsec process that takes into account the existing code review tools (codepipeline, codeguru) and also architectural reviews around design decisions (yes, it makes sense to take advantage of Cloud Security Posture Management tools and Lacework makes some.)

 

90-day checklist: The jog

I’m not a big runner but I make myself do it anyway, especially when I’m late (just kidding, kind of). You know that point in a run where you work through the plateau and then it’s no longer painful, it’s just like your legs are running on a motor? That’s what we want. We want the mechanisms and muscle groups you’ve been creating to feel like they are running in an oiled way.

There will always be day-to-day things to care about, but after around 90 days, hopefully you are getting into a cadence where you can pick your head up, look to execute longer-term security strategies, and establish mechanisms for continuous oversight.

Long-term strategy implementation

Bring your CFO and CEO the cost of downtime

This includes the calculation of likelihood x impact. Once you’ve run some numbers, get a business judgment call on all the work you know you need to do, but might not have the resources to accomplish. These should be business decisions that you (the security exec) raise, and then the business makes an informed decision on how to approach it. You won’t always get what you want–frankly, there’s a point where the ROI of security investments might hit a low enough point– but it’s on you to ensure that the business side can make clear-eyed decisions.

Embed a security engineer in your continuous integration (CI) and continuous delivery (CD) teams

CI/CD is not just a term, it’s a reality now, and any competitive entity will want to move from waterfall to agile development cycles. Amazon refers to these lean devops processes as “2-pizza teams,” I would order an extra pizza and add a hungry security engineer. No need to hire a long-time veteran, you can train a software developer to wear a security hat. 

Amazon did this, and found that it minimized appsec review times; I would suggest it also creates an atmosphere where the goals of the dev team (“make it work!”) line up better with the goals of the security team (“make it secure!”) and turn it into something better. Of course, if your security team is putting paved roads on the map, and using effective logging/monitoring, and all the other good stuff we’ve described, so much the better for your builders (and your security engineers).

Monitoring and reporting

Define your metrics for short- and long-term success

Define your metrics for short-term success (i.e., acknowledging a trouble ticket within 10 minutes) and long-term success (i.e., reducing dev cycles from 6 months to 6 weeks). When you take these outside the security organization, make your metrics business-oriented, even though they’re security specific. For example, what does this recent improvement in response time mean for business continuity? What does it cost if we fail to patch critical assets or continue to run code with vulnerabilities? How will we evaluate the security of new acquisitions to our company? Oh, and while you’re at it, look at the composition of your board– hopefully there’s a security person and if not, suggest that they get one. (Here’s a rolodex of folks interested in board seats, courtesy of Lacework! Yes I’m in it, yes I had to ask.)

Make what I call an “atta girl” file where you record your wins

These might be unblocking processes, speeding up deliverables, getting to “yes” with a regulator or compliance body, creating new business value, employee retention and upskilling, and so on. Regularly update C-level executives and board members on your wins, and keep them aware of business risks/losses.

Continuous improvement

Cultivate a culture of skepticism and growth

Some folks use anonymous suggestion boxes, others have office hours or other meetings for feedback. “Because we’ve always done it this way” is the death of productive feedback loops.

Create and maintain mechanisms for customer feedback to get back to the security shop

No matter what business you are in, security is a critical part of what you are delivering to your consumers.

Create mechanisms for taking action

You should be continuously refining the “gray area” of human decision making down to the truly novel or high stakes. This means codifying decisions (okay, so you have a finding — how do you take action on those?) and building a shop that solves big problems, by solving small problems.

 

💡CISO-to-CISO tip: "As you begin shifting workloads to the cloud, don’t forget to shift your people as well. Upskilling existing employees into cloud security experts is more cost-effective than external recruiting. Also, providing opportunities to learn new skills is a major driver of employee satisfaction. Identify the people across your organization who show an aptitude for cloud security (they won’t always be existing cybersecurity team members) and get them the skills they need to succeed.  I’ve leveraged AWS resources, and other third-party training tools to build an amazing team."

— Doug Fish, Director of Information Security, Mister Car Wash

 

Look at emerging issues

Carve out time to look at emerging issues like the security of ML models in your enterprise, your tolerance for employees using large language models (LLMs), including for code review, and other issues on the horizon. Again, there are some approaches that work better than others, but tune it to your business risk.

Make sure your team isn’t getting burnt out

Get a plant for your desk, it’s supposed to make people a little happier. I’m just kidding, but do take time to make sure you and your team aren’t hitting the burnout that hits so many security professionals. Use pager rotations to ensure that folks aren’t always “on,” and when folks are on time-off, respect it. The (security org) machine should be well built enough that you can move on without any one human, including yourself.

 

💡 CISO-to-CISO tip: "Automating responses to cybersecurity alerts offers many benefits, it is however, essential to strike a balance between automation and human oversight. Human expertise is vital for handling complex, novel threats and making critical decisions. Implementing a 'human-in-the-loop' approach, where automated systems assist human analysts, provides a balance that will lead to a stronger security posture."

– David Christensen, CISSP, VP, Chief Information Security Officer, PlanSource

Learn more

In my experience, CISOs are trying to do the right thing —  but good intentions are not enough. We need some repeatable mechanisms to get to a better, more mature state of security and to create a security team that enables the business to move forward. It’s a cliche by now that security should not be the shop of “no”— but what does that mean in practice? I think it means that the CISO takes responsibility to execute on a business mission while minimizing risks, and making accepted risks conscious decisions. 

Take a look at The CISO playbook for cloud security for a little light reading before you fall asleep (lol) and share this and repost with your thoughts to let me know any tips and tricks you wish you knew!  

 

Categories

• Blog
• Cloud Security
• DevSecOps

• CNAPP
• Compliance
• CSPM
• DevOps
• Enterprise security
• Shift Left security
• Startup security