Research

In our first post on Leveraging Threat Intelligence in Security Monitoring (TISM), Benefiting from the Misfortune of Others, we discussed threat intelligence as a key information source for shortening the window between compromise and detection. Now we need a look in terms of security monitoring – basically how monitoring processes need to adapt to the ability to leverage threat intelligence. We will start with the general monitoring process first documented in our Network Security Operations Quant research. This is a good starting point – it details all the gory details involved in monitoring things. Of course its focus is firewalls and IPS devices, but expanding it to include the other key devices which require monitoring isn’t a huge deal. Network Security Monitoring   Plan In this phase we define the depth and breadth of our monitoring activities. These are not one-time tasks but processes to revisit every quarter, as well as after incidents that triggers policy review. Enumerate: Find all the security, network, and server devices which are relevant to the security of the environment. Scope: Decide which devices are within scope for monitoring. This involves identifying the asset owner; profiling the device to understand data, compliance, and policy requirements; and assessing the feasibility of collecting data from it. Develop Policies: Determine the depth and breadth of the monitoring process. This consists of two parts: organizational policies (which devices will be monitored and why); and device & alerting policies (which data will be collected from. It may include any network, security, computing, application, or data capture/forensics device. Policies For device types in scope, device and alerting policies are developed to detect potential incidents which require investigation and validation. Defining these policies involves a QA process to test the effectiveness of alerts. A tuning process must be built into alerting policy definitions – over time alert policies need to evolve as the targets to defend change, along with adversaries’ tactics. Finally, monitoring is part of a larger security operations process, so policies are required for workflow and incident response. They define how monitoring information is leveraged by other operational teams and how potential incidents are identified, validated, and investigated. Monitor In this phase monitoring policies are put to use, gathering data and analyzing it to identify areas for validation and investigation. All collected data is stored for compliance, trending, and reporting as well. Collect: Collect alerts and log records based on the policies defined under Plan. This can be performed within a single-element manager or abstracted into a broader Security Information and Event Management (SIEM) system for multiple devices and device types. Store: Collected data must be stored for future access, for both compliance and forensics. Analyze: The collected data is analyzed to identify potential incidents based on alerting policies defined in Phase 1. This may involve numerous techniques, including simple rule matching (availability, usage, attack traffic policy violations, time-based rules, etc.) and/or multi-factor correlation based on multiple device types. Action When an alert fires in the analyze step, this phase kicks in to investigate and determine whether further action is necessary. Validate/Investigate: If and when an alert is generated, it must be investigated to validate the attack. Is it a false positive? Is it a real issue that requires further action? If the latter, move to the Action phase. If this was not a ‘good’ alert, do policies need to be tuned? Action/Escalate: Take action to remediate the issue. This may involve a hand-off or escalation to Operations. After a few alert validations it is time to determine whether policies must be changed or tuned. This must be a recurring feedback loop rather than a one-time activity – networks and attacks are both dynamic, and require ongoing diligence to ensure monitoring and alerting policies remain relevant and sufficient. What Has Changed Security monitoring has undergone significant change over the past few years. We have detailed many of these changes in our Security Management 2.5 series, but we will highlight a few of the more significant aspects. The first is having to analyze much more data from many more sources. We will go into detail later in this post. Next, the kind of analysis performed on the collected data is different. Setting up rules for a security monitoring environment was traditionally a static process – you would build a threat model and then define rules to look for that kind of attack. This approach requires you to know what to look for. For reasonably static attacks this approach can work. Nowadays planning around static attacks will get you killed. Tactics change frequently and malware changes daily. Sure, there are always patterns of activity to indicate a likely attack, but attackers have gotten proficient at evading traditional SIEMs. Security practitioners need to adapt detection techniques accordingly. So you need to rely much more on detecting activity patterns, and looking for variations from normal patterns to trigger the alerts and investigation. But how can you do that kind of analysis on what could be dozens of disparate data sources? Big data, of course. Kidding aside, that is actually the answer, and it is not overstating to say that big data technologies will fundamentally change how security monitoring is done – over time. Broadening Data Sources In Security Management 2.5: Platform Evolution, we explained that to keep pace with advanced attackers, security monitoring platforms must do more with more data. Having more data opens up very interesting possibilities. You can integrate data from identity stores to trace behavior back to users. You can pull information from applications to look for application misuse, or gaming legitimate application functionality including search and shopping carts. You can pull telemetry from server and endpoint devices, to search for specific indicators of compromise – which might represent a smoking gun and point out a successful attack. We have always advocated for collecting more data, and monitoring platforms are beginning to develop capabilities to take advantage of additional data for analytics. As we mentioned, security monitoring platforms are increasingly leveraging advanced data stores, supporting much different (and more advanced) analytics to find patterns among many different data sources.

This is the first post in a series on the future of information security, which will be the basis for a white paper. You can leave feedback here as a blog comment, or even directly submit edits over at GitHub, where we run the entire editing process in public. This is the initial draft, and I expect to trim the content by about 20%. The entire outline is available. A Disruptive Collision At the best of times, the practice of information security is defined by disruption. We need to respond to business and technology innovations – not only from those we defend, but also from their attackers. Security is never really in control of our own destiny – we are tasked with managing the risks of decisions made by others, in the face of entire industries (and economies) dedicated to discovering new ways of stealing or hurting them and us. We are reactive because those we protect and those who attack are never fully predictable – not because of an inherent failing of security. But the better we predict these disruptions, and the better we prepare our response, the more effective we are. As analysts, we at Securosis focus most of our research on the here and now – on how best to tackle the security challenges faced by CISOs and security professionals when they show up to work in the morning. Occasionally as part of this research we note trends with the potential to dramatically affect the security industry and our profession. We currently see what appears to be the largest combination (collision) of disruptive forces since the initial adoption of the Internet – with implications for security far beyond our first tentative steps onto the global network. Additionally, we have identified six key trends which are currently altering the practice of security. This combination of external and internal change is fundamentally transforming the practice of security. This paper starts with a description of the disruptive forces and the native security trends, but its real objective is to lay out their long-term implications for the practice of security – and how we expect security to evolve for security professionals, security vendors, and cloud and other infrastructure providers. Through the report we will back up our analysis with real-world examples that show this transformation isn’t a vague possibility in a distant future, but is already well under way. But although these changes are inevitable, they are far from evenly distributed. As you will see, this provides plenty of time and incentive for professionals and organizations to prepare. Two Disruptive Innovations Clayton Christensen first coined the term “disruptive technology” in 1995 (he later changed the term to “disruptive innovation”) to describe new business and technology practices that fundamentally alter, and eventually supersede, existing ones. Innovation always causes change, but disruptive innovation mandates change. Innovation creates new opportunities and disrupts old ones. The technology world is experiencing a combination of two disruptive innovations simultaneously colliding and reinforcing each other. Cloud computing alters the consumption and delivery models for technology at both economic and technical levels. Advances in mobile technology are changing our access and consumption models, and reinforcing demand for the cloud – particularly at scale. Cloud Computing Cloud computing is a radically different technology model – it is not simply the latest flavor of outsourcing. It uses a combination of abstraction and automation to achieve previously impossible levels of efficiency and elasticity. This, in turn, creates new business models and alters the economics of technology delivery and consumption. Sometimes this means building your own cloud in your own datacenter; other times it means renting infrastructure, platforms, and applications from public providers over the Internet. Public cloud services eliminate most capital expenses, shifting them to on-demand operational costs instead. Private clouds allow more efficient use of capital, may reduce operational costs, and make technology more responsive to internal needs. Cloud computing fundamentally disrupts traditional infrastructure because it is more responsive, more efficient, and potentially more resilient and cost effective than our old ways of doing things. These are the same drivers that pushed us toward application service providers and virtualization. Public cloud computing is even more disruptive because it enables organizations to consume only what they need without maintaining overhead, while still rapidly responding to changing needs at effectively infinite scale (assuming an adequate checkbook). Every major enterprise we talk with today uses cloud services, and even some of the most sensitive industries, such as financial services, are exploring more extensive use of public cloud computing. We see no technical, economic, or even regulatory issues slowing this shift. Many security professionals focus on the multitenancy risks introduced by cloud, but abstraction and automation are more significant than shared infrastructure or services. Many security controls today rely on knowing and managing the physical resources that underpin our technology services. Abstraction breaks this model by virtualizing resources (including entire applications) into resource pools managed over the network. We give up physical control and shift management functions to standard network interfaces, creating a new management plane. This separation and remote management challenge or destroy traditional security controls. Abstraction is central to virtualization, and we are at least nominally familiar with its issues. But this kind of automation is specific to the cloud, and adds an orchestration layer to efficiently utilize resource pools. It enables extreme agility, such as servers that exist only for hour or minutes – automatically provisioned, configured, and destroyed without human interaction. Application developers can check in a piece of code, which then runs through a dozen automated checks and is pushed into production on a self-configuring platform that scales to meet demand. Security that relies on controlling the rate of change, or that mandates human checks, simply cannot keep up. Virtualization is the core enabling technology of abstraction, and Application Programming Interfaces (APIs) are the core enabler of automation. The elasticity and agility they together provide enable new operational models such as DevOps, which consolidate historically segregated management functions to improve efficiency and responsiveness. Combined with greater reliance on public cloud computing, the Internet itself becomes the interconnected platform for our applications and workloads. Defining DevOps

During my total and complete laptop fail for this week’s Firestarter, I was trying to make the point that large software projects have a considerably higher probability of failure. It is no surprise that many government IT projects are ‘failures’ – they are normally managed as ginormous projects with many competing requirements. It worked or the Apollo missions so governments doggedly cling to that validated model. But in the commercial environment Agile is having a huge and positive impact on software development. Coincidentally, this week Jim Bird discussed the findings of the 2013 Chaos Report. In a nutshell the topline was “More projects are succeeding (39% in 2012, up from 29% in 2004), mostly because projects are getting smaller”. But Jim points out that you cannot conjure up an Agile development program like the Wonder Twins activate their superhero powers – Agile development processes are one aspect, but program management across multiple Agile efforts is another thing entirely. A lot of thought and work has gone into this over the last few years, and things like the Scaled Agile Framework can help. Still, most government projects I have seen employ no Agile techniques. There is a huge body of knowledge out on how to get these things done, and industry leads the public sector by a wide margin. I used to get a lot of spam with hot stock tips. I was assured a penny stock was about to shoot through the roof because a patent was approved, and got plenty of dire warnings about pharmaceuticals firm failing clinical trials. Of course the info was bogus, but Mr. Market, the psycho he is, actually reacted. Anonymous bloggers could manipulate the market simply by leaving comments on blogs and message boards, offering no evidence but generating huge reactions. If you are a day trader this can pretty much ensure you will make money. This whole RSA deal, where they allegedly took $10M from the NSA to compromise security products, has the same feel – it sounds believable, but we are seeing a huge backlash without any sort of evidence. It feels like market manipulation. Could RSA have been bribed? Absolutely. Would the NSA conduct this business without leaving a paper trail? Probably. But would I buy or sell stocks based on spam, anonymous blogs posts, or my barber’s recommendation? No. That is not an appropriate response. Nor will I grandstand in the media or start a new security conference, trying to hurt RSA, because of what their software division did or did not do years ago. That would also be inappropriate. Pulling the ECC routines in question? Providing a competing solution? Providing my firm some “disaster recovery” options in case of compromised crypto/PRNG routines? Those are all more appropriate responses. For those of you who asked about my upcoming research calendar, I am excited about some projects that will commence in a couple weeks and complete in Q2. First up will be an update to the Big Data Security paper from mid-2012. SOOOO much has happened in the last 6-9 months that a lot it is obsolete, so I will be updating it. Gunnar and I are working on a project we call “Rebel Federation”, which is how we describe the assembly of an identity management solution based on best of breed components, rather than a single suite / single vendor stack. We will go through motivations, how to assemble, and how to mitigate some of the risks. And given the burst of tokenization inquiries over the past 60 days, I will be writing about that as well. If you have questions, please keep them coming – I have not yet decided on an outline. And finally, before RSA, I promise to launch the Security Analytics with Big Data paper. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on Database Denial of Service. David Mortman and Adrian Lane will be presenting at Secure360. Mike and JJ podcast about the Neuro-Hacking talk at RSA. Favorite Securosis Posts Mike Rothman: The Future of Information Security. Rich is our big thinker (when he gets enough sleep, at least) and I am fired up to read this series about how we need to start thinking about information security moving forward. The technology foundation under us is changing dramatically, and that won’t leave much of current security standing in the end. Either get ahead of it now, or clean up the rubble of your security program. Adrian Lane: Southern Snowpocalypse. It snowed here in Phoenix last year, but nothing like it did in ATL yesterday. It does not matter where snow hits – if it is at the wrong time and a city is unprepared, it’s crippling. Other Securosis Posts Firestarter: Government Influence. Leveraging Threat Intelligence in Security Monitoring: Benefiting from the Misfortune of Others. Summary: Mmm. Beer. Favorite Outside Posts Jamie Arlen: James at ShmooCon 2014. Totally self-serving, I know, but awesome none the less. Gunnar: NFC and BLE are friends. Adrian Lane: Pharmaceutical IT chief melds five cloud security companies to bolt down resource access. This is my first NetworkWorld fave – usually I ridicule their stuff – but this is a good description of a trend we have been seeing as well. And you need some guts to walk this path. Mike Rothman: Volunteer at HacKid! If you’re on the west coast and have kids, you should be at HacKid, April 19-20 in San Jose. Plenty of opportunities to volunteer. I’ll be there (with my 10 year old twins), and I think Rich is planning to attend as well. See you there! Research Reports and Presentations Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Top News and Posts Software [in]security and scaling automated code review. Just Let Me Fling Birds at Pigs Already!