Your First 90 Days as Security Lead, Part 2: Developing a Plan and Getting to Work

Jan 14 2019
HackerOne

You’ve just been named as your organization’s new head of security. So what do you do first? Read part one of this series, “Building Your Security Foundation”, then come back here to continue.

At this stage, your mind is probably flooded with things to do and potential places to begin. That’s all great information to parse, but there are a few areas where you should focus as you get underway. Start by understanding the current situation, then working with users to get their perspective, and surveying other leaders to be better prepared for where your organization wants to be in the future. With that information, you’re best equipped put your plan into action.

Determine today’s baseline

Two men solve a problem at a computer

One of your first tasks should be to assess your current security measures to really understand your broader security stance rather than trying to react to every incoming issue. That means talking with your security team as well as with developers, engineers, legal, finance, HR, marketing, compliance, and others to understand their view of risks and threats facing your organization. By asking questions about past incidents, close calls, mistakes, and lessons learned, plus observing past decisions and actions, you’ll be better able to develop a risk framework and prioritizations. 

During these interviews, you’ll also have a chance to position risk as a thing to manage, not a thing to eliminate. For example, you can eliminate any risk of a data breach by deleting all of your data. But that’s just silly. Customers and workers need access to that data. So how do you manage the risk? By giving access to the people who need the data while protecting it from those who don't.

The point is that your data and technologies have to be accessed, so they are, at least in some respects, open. Your security approach should be open as well. Hiding the risks—security through obscurity—does nothing to help mitigate them, and even those outside of your security team may have ideas and options to consider. Developers and engineers need to know the risks in order to help mitigate them at the base code levels. Also, everyone should be encouraged to consider security, so actively engaging with them now gives them more incentive to participate if you need them to later.

It’s crucial to evaluate the severity and criticality of the security landscape since you need to know what you’re protecting before you can protect it. These conversations precede an asset inventory, where you identify everything in your purview—hardware, software, cloud services, access points, users, and so on. Then, look at the processes involved with provisioning, maintaining, procuring, and using those systems. Also look at current vulnerability management processes, such as how incoming bug reports are managed (if at all) and how disclosure is handled. 

This all sparks further conversations with infrastructure engineers, architects, IT, developers, and others. At all times, remember that you’re not there to place blame, you’re there to provide solutions.

Once you begin to understand the assets and the processes, you’ll spark new conversations on how your apps are developed, how bugs are reported and fixed, how products are released, how updates are disseminated, how user accounts are provisioned, and more. It will open a new level of collaboration between security and the rest of the organization, all aimed at reducing risk and developing solutions early rather than after the fact.

Your goal here is to change the conversation by having conversations. The openness you display around security can shift how your organization approaches the entire topic. You’ll never eliminate all of the cybersecurity risks, but by being transparent and open, you’ll be better prepared to manage and respond to any future threats.

Walk the user’s walk 

Man works at computer

Up to this point, you’ve taken an internal approach, working with developers and internal stakeholders for an inside-out perspective. In your first 90 days, it’s critical to also look at security from the user’s perspective, and that means both employees and customers. 

For example, have IT walk you through the process of provisioning a new employee with accounts, passwords, hardware, etc. Then, pretend you’re a new customer and do the same, from first marketing interaction of gathering contact information to entering credit card numbers to understanding access, passwords, administration, and data flow. 

External assessments can play a part here as well. Bug bounty programs, penetration tests, scans, and vulnerability disclosure policies can identify bugs and potential issues from the perspective of those outside your organization. They provide a means for uncovering issues in areas or with techniques you may not have considered.

It’s an involved process, to be sure, but taking these steps can identify even more security gaps and areas of focus as you put together your plan. 

Look to tomorrow

The trajectory of your organization is, from your perspective, more important than the status quo. As you build or adjust your team, that trajectory will define which roles and skills you need, how much budget is required, where processes need to be defined or reworked, and what tools or techniques need to be replaced or added. 

During your conversations with stakeholders, talk about future needs and fears. Legal and compliance might have insight into future regulatory concerns, while marketing may be worried about the positioning of security towards a certain market. 

As new projects or products are developed, get involved early and partner with development teams by helping them apply the appropriate security practices. Then, as everyone becomes more comfortable, migrating existing products will be both easier and more understandable. 

Get to work implementing your plan

Two men at computer work through a possible security threat

You’ve been the head of security for a couple of months, so now it’s time to put a plan in place and get to work. But where do you focus your efforts and which threats should you prioritize? 

Remember that any security threat is also a business threat. Aligning your team to business priorities is important, as is framing your security strategy in business terms. For example, talking to your executives about patch management will elicit yawns. But the conversation becomes vastly more interesting when you explain that a breach in a specific area by a specific threat would impact key business goals. It also puts the importance in terms most business leaders understand: revenue.

Prioritize your threat landscape

Threat modeling is a way to identify and prioritize potential security threats. It gives you a criminal’s view of your organization, identifies weak spots, and lets you get to work hardening those gaps. A threat might be based on the security gap in your technologies or the assets at risk from a gap or a combination of the two. Whatever your methodology (and many are available), it’s a logical way to set your security strategy early on.

Further external assessments, such as bug bounty programs, can also highlight areas where threats are more likely. Maybe a compromised technology was used in various apps across your business. You might not even be aware, but independent white hat hackers will quickly identify such a gap. 

This is where good risk management comes into play and works to save your company money. Incorporating a financial aspect to your prioritization also puts it in terms others will easily understand. For example, penalties for a breach to customer data are likely more impactful than breaches to, say, product information. So if a specific risk is projected to cost $10,000 if exploited, but a fix would cost $50,000, it would have a low priority.

By modeling those threats, and their potential impact, you’ll build a picture of your most sensitive areas and gaps. This is how your understanding of your threat landscape informs your strategy and priorities going forward. 

Develop your priorities

At this point, your prioritized list of projects should be apparent and point to items that are critical to your brand or your organization’s livelihood. These priorities cannot be developed within your team alone, however. Your early conversations can help inform the prioritization, but collaboration at this point is important so you can understand the impact of the priorities. Maybe development and engineering don’t have the resources to work on something you deem as critical. Maybe compliance and legal, or even marketing, have different ways to measure prioritizations. 

Collaboration is key, especially since many of the fixes will be the responsibility of other teams. Furthermore, effective planning gives these teams enough time to weave security priorities into their own long list of projects. It also builds goodwill across the organization by helping to reduce frustrating fire drills.

Share your knowledge

As you get to work, you’ll undoubtedly seek advice and knowledge from other parties outside of your organization. Part of the paradigm shift from the fortress to the airport model of security is also in external transparency. It benefits you, and it’s a two-way street. Every company, even competitors, need to collaborate on threats and solutions. When we share knowledge, we all become better at identifying and counteracting threat actors and attack trends. 

Many industry organizations are taking the lead on this front, such as Auto-ISAC and FS-ISAC, while government agencies, from the Federal Trade Commission to the Food & Drug Administration to the European Commission, are also offering advice and guidance. Their transparency helps you, so please consider being transparent yourself.

Another positive result of transparency is the MITRE ATT&CK knowledge base. It provides a framework for describing the behavior of attackers and can help organizations understand their defense capabilities. It’s also a great resource for threat modeling, especially for organizations new to the practice. 

HackerOne also provides a public view of hacktivity, where the details of disclosed vulnerability reports are available for all to see and learn from. While some of our customers redact the finer details, many others provide full disclosure, including communications between internal security teams and the reporting hacker, as well as the awarded bounty value, vulnerability categorization, and more.

Keep your eye on the prize

Remember that you’ve just begun your first 90 days as the security lead. You’ll obviously want to show progress (and areas of improvement) over the next several quarters and years, so the baseline you develop today will give you a set of benchmarks against which you can measure progress over the coming months. 

Also, remember that you’ll never eliminate all threats, you’ll just change the threat landscape by mitigating some as criminals open up others. Your job is to reduce security risks. Only by being a vocal participant in your organization (and in your industry) will you be effective at your new job. 

The cybersecurity landscape has changed drastically over the past few years. Secrecy has been replaced by transparency, and for every company outed for their highly-preventable security gaps, many other organizations have chosen to proactively share information and build a more secure environment for everyone. By taking an open, collaborative approach to security, both internally and externally, you’re giving yourself a better chance at success. 

Best of luck! 

Related Posts