It’s 3pm on a Wednesday, and you’re really just done with the week already. You hear that “ping” from your Slack and know that you set notifications for direct messages only, which means, ugh, you have to pay attention to this one. It’s your boss, and she’s telling you to check your email. Then you see it, the dreaded audit documentation request. This will take you the rest of today and most of tomorrow.
When security analysts choose technology, they approach the process like a mechanic looking to purchase a car. They want to look under the hood and see how the product works. They need to evaluate the product as a technologist. On the other hand, the c-suite has different evaluation criteria. Senior leadership approaches the process like a consumer buying a car.
The phone rings. Your email pings. Your marketing team just told you about a flood of messages on social media and through live chat that there’s a service outage. You thought your Monday morning would be calm and relaxed since people are just returning from the weekend. How do you start researching all of these incoming tickets? How do you know which ones to handle first? Is this just a hardware failure, or are you about to embark on a security incident investigation like Log4j?
Cybersecurity can often seem intimidating for IT teams. After all, things like “threat hunting,” “red teaming,” and “blue teaming” are not used in IT operations. On the other hand, just because these words are terms of art doesn’t mean that they’re activities you don’t do already. You’re probably already using log data as part of your IT operations incident response.
As an IT operations manager, you spend a lot of your time mitigating service outages and service level risks. You worked diligently to get the right people, products, processes, and partners in place to meet your goals. You managed to ensure continued uptime. You’ve reduced the number of tickets and the cost per ticket. And for your efforts, you’re rewarded with managing your company’s cybersecurity program. The problem? You’re not a security specialist.
With the rising tide of data breach awareness, your senior leadership is asking you to mitigate cybersecurity risk with security analytics. You’ve built up the use cases and started researching different platforms. Then, you realized: you’re not sure you have the budget. The typical security analytics platforms come with upfront technology costs as well as the “hidden fees” associated with training your team members. You know you need to use analytics to help mitigate risk.
It’s been a week. A long week. After the most recent Board of Directors meeting, your senior leadership tasked you with finding a security analytics solution. Over the last month, you’ve worked with leadership to develop some basic use cases to determine which solution meets your security and budget needs. You started your research, but everything on the market seems really overwhelming.
It’s time again for another meeting with senior leadership. You know that they will ask you the hard questions, like “how do you know that your detection and response times are ‘good enough’?” You think you’re doing a good job securing the organization. You haven’t had a security incident yet. At the same time, you also know that you have no way to prove your approach to security is working. You’re reading your threat intelligence feeds.
What kind of log information should be reported up the chain? At a certain point during log examination analysts start to ask, “What information is important enough to share with my supervisor?” This post covers useful categories of information to monitor and report that indicate potential security issues. And remember: reporting up doesn’t mean going directly to senior management. Most issues can be reported directly to an immediate supervisor.