A funny thing happened on the way to designing threat intelligence programs….we forgot about the risks! We as an industry tend to buy a lot of tools, sift through a lot of data, and send out a bunch of reports, but we forget to ask what we are really doing all of this for.
So let’s quit failing and forgetting our original goals of implementing threat intelligence programs, and let’s make them effective and efficient for our organizations. Here are some questions to start asking yourself about your threat program:
I always like to start with the NIST Risk Framework because it has truly stood the test of time. It also provides key foundational elements that run in a cyclical fashion, much like any good program should run with a feedback cycle.
More importantly, each component of a threat intelligence program needs to tie back to your risk program. If you have prioritized certain areas of your business as critical risks then you may want to craft components of the program in support of these priorities. For example, say that you have invested heavily in an online service through which your customers can check and pay their bills, grab their account information, or submit questions or concerns to customer service. In a recent review of risks to your company, you have also flagged this service as critical to helping increase company revenue over the next 1-3 years. If something happens to this service, revenue could be impacted by, say, 20% percent. This is fairly significant!
In this case, given the impact on the business, you will want your threat intelligence program to be fully aware of this service, the assets involved in supporting this service, software packages and other applications that integrate with it, who has access to the sensitive data, and even how it’s maintained. With this knowledge in hand, the threat intelligence team can look for chatter about such a service on the internet, potential new vulnerabilities affecting those specific assets, as well as keep an eye out for unusual activity against the site, be it increased activity at “off” hours, requests coming from suspicious IP addresses, or a high number of unsuccessful login attempts against certain accounts.
In addition to knowing what assets need to be monitored as part of the threat program (since threats affect risk), we also have to consider two other factors very carefully as we build our threat intelligence programs: staffing requirements for the program and the deliverables the team provides to other functional areas within the company. It’s important for team members to clearly understand their role and responsibilities—and how those relate to overall company goals—and it’s equally important to measure progress so that impact can be assessed. How we do that is tricky, but there are ways.
Additionally, we tend to neglect to limit the scope of our programs; we put so much into the expectations of our programs that they simply fail.
Threat intelligence is supposed to be about sharing information with others who are trying to meet the same goal: reduce risk in our organizations. Let’s share information about how to accomplish some of the above and talk about the best and worst ways to reduce risk for our organizations during the Risk v Threat: Threat Intelligence Exposed round table discussion at InfoSec World 2017.
About the author: Kristy Westphal, versatile information technology professional of 23 years with specific experience in providing advisory and management services in the area of information security and risk, is currently employed as the Senior Manager of Security Tools at Charles Schwab. She has previously worked as the Director, Risk and Assurance with Vantiv and Director, Security Operations for T-Systems North America. Kristy will facilitate the round table discussion, Risk v Threat: Threat Intelligence Exposed, at InfoSec World 2017 on Monday, April 4, 2017.