Seven Deadly Sins of Security Teams
When I talk to organizations and executives, I see the same security mistakes and misconceptions over and over again. I see security leaders make these mistakes and wonder how they could have alienated their coworkers and their executive leaders. I see businesses and executives confused why they keep getting breached and why they are spending so much on security incidents, but aren’t making progress in preventing incidents.
This is meant to be an incomplete list of mistakes I see security organizations make. Use it to sanity check your security organization and their strategy.
Compliance (and Regulatory Frameworks)
Many security teams use regulatory and compliance frameworks to set their strategy, vision, and roadmap. Instead, they should be using business risks and adversary intelligence to get more effective and aligned goals. Start with security objectives, business goals, data, adversary intelligence, and critical thinking to build your program strategy, vision, and roadmap. When you can objectively say that your program secures the organization and protects user data, then map your existing controls to laws and compliance frameworks for a narrative that’s palatable for customers and regulators.
Product (Security)
Modern security teams and security teams at technology organizations often put a heavy emphasis on product security. Often hiring for product security before corporate security or security operations. This happens for a variety of reasons, sometimes because the CISO or head of security reports into the CTO and sometimes because security teams wrongly think that focusing on the product is the best way to serve a technology company’s business from security.
First-party products (and custom web applications) are almost never used by adversaries in intrusions and attacks. Focusing too many resources on product security could weaken your organizations overall security, as most adversaries are using delivery methods like phishing and credential reuse, and focusing on exploitation of ubiquitous assets like endpoints, vendors, and commercial products to establish access. Don’t just focus on product security, make sure your entire security program is broad enough to cover all your business’s risks. Security operations and corporate security will be more important and impactful than product security for the majority of organizations.
Phishing (Training)
Sending fake phishing e-mails to your employees is actively harmful. It rarely increases awareness and typically doesn’t help your employees discern fraudulent e-mails from legitimate ones. Instead, it instills a sense distrust between security and the rest of the organization and it makes employees feel like the security team is trying to trick them into clicking on something, only training the organization to be afraid of their security team.
Instead, you want to build the opposite relationship. Employees should see security as a resource. Security should build a blameless incident culture, where employees are rewarded for telling security about accidentally clicking on malicious e-mails or installing malicious software.
It is security’s responsibility to detect and prevent phishing, not an employee’s responsibility to scrutinize every e-mail they get while they are trying to do their job. Don’t think that security awareness training will do any better than technical controls here. Any phishing training should be focused on blameless reporting and clear warnings. Reporting a potential phishing e-mail should be easy, and security’s response should be quick and clear. Warnings about potentially malicious e-mail should be obvious and easily understood by every employee.
Fear (Saying No)
Security teams like to use fear and blocking processes to enforce security policies. Sometimes, it’s security’s job to say that something is too risky to the business, but often security teams say that without evidence or accuracy. Also, security teams are often trying to give an acceptance or denial when they should really be advising a business owner about a risk decision. Use these opportunities to say yes and build successful relationships with different parts of the organization.
Security should always be trying to find solutions and controls that meet their (reasonable) security requirements and allow the business to operate effectively and efficiently. If the business needs to do something that security deems too risky, it’s security’s responsibility to come up with new and creative controls and processes to allow the business to operate securely (and if more resources are required to do that, it’s security’s responsibility to advocate for them).
Patching (Fixing Everything)
Don’t get caught in the Sisyphean cycle of trying to patch every system and remedy every vulnerability. You will never be able to fix everything, and trying to will cause you to make big picture mistakes that will ultimately lead to failure.
Instead, focus on fixing only the threats that matter. Did you know that most vulnerabilities that don’t have public exploit code available, aren’t exploited in the wild? If a vulnerability is not being actively exploited and it doesn’t have public exploit code available and it’s not a ubiquitous target, you probably don’t have to patch it. Make sure your operations team is aware and move on.
Belief (Believing Vendors)
Most security teams think their security products and services solve all their problems, but most vendors don’t care or have the context to understand your business or your adversaries. You have to develop your own strategy and vision, and use your and your team’s judgement to make the right decisions.
Don’t believe vendors that you need a solution or that their solution does what it says it does. Use your own team’s expertise to validate that you need any solution or control and that it effectively identifies, detects, prevents, responds to, or recovers from your adversaries. For example, any endpoint vendor will tell you that their solution solves all your endpoint needs, but depending on your security requirements, you may need a wide variety of solutions working in tandem to complete your endpoint security strategy.
Prioritization
Teams are rarely working on their most important risks or their most impactful projects. Make sure you are constantly evaluating your priorities and don’t be afraid to stop progress on one project for another if it will benefit the organization.
Remember to continuously come up to the surface to observe and orient to make sure your teams are focused on the right projects and issues. Keep your feedback loops tight, so that you constantly receive new information, react, and reprioritize.
