Fault tolerance is "the property that enables a system (often computer-based) to continue operating properly in the event of the failure of (or one or more faults within) some of its components. If its operating quality decreases at all, the decrease is proportional to the severity of the failure..." (1)
Fault tolerance is integral to systems engineering of critical systems.The assumption is that systems will fail and that the impacts of those failures must be controlled. An example approach would be to mandate that a system be two fault tolerant. This would then drive the design of three inhibits, any one of which could prevent the failure of the system. For a physical system, the failure may be physical failure. For an information system, the failure will likely be loss of confidentiality, integrity, or availability of critical data or a critical business process.
Fault tolerance can and should be applied to infosec as well. When we plan our defenses, we should assume that some defenses will fail to mitigate the risks they were designed to prevent. We should assume that some vulnerable conditions will be taken advantage of. To plan infosec inhibits, we must understand the attack path between the causes of our risk (likely a threat) and where the consequences are realized. It is along these paths that we can then document inhibits. Whether it be a firewall, code whitelisting, requiring a written form before receiving privileges, or detecting and responding to threats before consequences are realized, we can capture those along the attack path. Currently we refer to this as 'defense in depth'. We all have a general understanding of what it means, but the above approach provides a concrete and quantifiable method for implementing it.
A few months ago there was a significant discussion on whether pen test teams should have a 'zero day' card they could use during a pen test. What this is really asking is, "Should we test whether the system's backup defenses can be relied upon in case of a failure of primary defenses?" Or, in other words, "Is the system fault tolerant?" The answer is we should absolutely include a 'zero day' card. Part of any pen test should be to articulate which defenses, inhibits, or mitigating conditions (whatever you call them) failed. However, it a system is supposed to implement 'defense in depth', then a 'zero day' card allows us to test that assertion by simulating the failure to see how well the system's defenses handle a failure. The documentation simply needs to be able to articulate that a failure was simulated to test the fault tolerance of the system.
Ultimately, we should plan for our information systems to be fault tolerant, even under purposeful information security attack. One fault tolerant, two fault tolerant, three fault tolerant... Regardless the standard set, not planning for fault tolerance is assuming the system's defenses will function perfectly. An inherently flawed assumption.
Friday, March 1, 2013
Wednesday, February 27, 2013
The Inside Liar
A significant topic for risk management these days is the insider threat. While it is accepted that the insider is the most likely threat actor, we have very little ability to deal with the insider threat. We generally treat them as an exterior threat: we look for their malicious actions and consequences. Whether it be sabotage or the loss of an organization's protected data, we see the results of the threat's actions and then attempt to find the root cause of what happened, hopefully associated with a threat actor (be it insider or exterior threat). However this is extremely hard. The complexity of our information systems provides ample space to hide malice.
There is another way: FIND THE LIE
If you ever watch an episode of COPS, after they have the situation under control, they break up the parties and ask a simple question, "So what happened here?" The reason is that, once they have the statements of the various parties, their job changes. They are no longer trying to find 'root cause', they are trying to figure out who is lying. When they find the liar, they've found the threat.
This offers a unique way for us to find insider threats. Rather than look for the consequences of their actions, look for the lies. From the second they get to the door to the minute they leave we expect our staff to assert information. They assert that they have a legitimate badge and that the badge represents them. They assert that they have a legitimate account on our information systems. They assert that they have a legitimate reason to access information through access forms and user agreements.
To realize a consequence, our threat must lie. Whether it's about why they are accessing information, why they are using a system, or why they are entering an area, they must lie. Those lies provide us an opportunity to detect our insiders. By processing the wealth of information we have on our users, we can look not for malicious actions and consequences, but instead for the lies that precede them. While threats will actively attempt to cover up their their malicious actions and consequences, they will continuously generate more and more lies as they do so providing us additional opportunities to detect them.
It is time we focused our defensive efforts where we have the advantage and where our attackers do not. While threats may have the advantage when it comes to hiding their malicious actions within the vast complexity of our information systems, a lie begets a lie. And a lie has short legs.
There is another way: FIND THE LIE
If you ever watch an episode of COPS, after they have the situation under control, they break up the parties and ask a simple question, "So what happened here?" The reason is that, once they have the statements of the various parties, their job changes. They are no longer trying to find 'root cause', they are trying to figure out who is lying. When they find the liar, they've found the threat.
This offers a unique way for us to find insider threats. Rather than look for the consequences of their actions, look for the lies. From the second they get to the door to the minute they leave we expect our staff to assert information. They assert that they have a legitimate badge and that the badge represents them. They assert that they have a legitimate account on our information systems. They assert that they have a legitimate reason to access information through access forms and user agreements.
To realize a consequence, our threat must lie. Whether it's about why they are accessing information, why they are using a system, or why they are entering an area, they must lie. Those lies provide us an opportunity to detect our insiders. By processing the wealth of information we have on our users, we can look not for malicious actions and consequences, but instead for the lies that precede them. While threats will actively attempt to cover up their their malicious actions and consequences, they will continuously generate more and more lies as they do so providing us additional opportunities to detect them.
It is time we focused our defensive efforts where we have the advantage and where our attackers do not. While threats may have the advantage when it comes to hiding their malicious actions within the vast complexity of our information systems, a lie begets a lie. And a lie has short legs.
Monday, February 25, 2013
Infosec Management Is The Problem
I regularly hear keynotes, presentations, and press releases from industry and, in particular, the government, about how there are simply not enough information security professionals to do the jobs available. They seem to imply that what we need is a larger pool of information security professionals. I think this is patently untrue.
The unavailability of infosec professionals is a manufactured shortage. It's controlled by many factors: specialization within information security, required certifications, fragmented compliance standards, required software qualifications, clearances, and job locations to name a few. Infosec, cybersec, or whatever you want to call it is one of the coolest yet most accessible STEM jobs available. There is a huge body of programmers, systems administrators, and technology professionals who would gladly work in infosec. No, what we have is a management problem.
Management Problem 1: Who we will hire.
If you are CYBERCOM, you want 4,000 qualified cyber security professionals. Except you want them in the Washington D.C. area with a TS/SCI clearance. If you are DHS, you still want them with a clearance as well as an arbitrary certification. If you are a business, you want them with broad infosec knowledge, experience on the tools you've bought, certification in your area of specialty, and experience in your specific compliance regimen. The frank fact is that deep experience is somewhat mutually exclusive with specialization in your business area. As anyone gains experience, they're going to have it mostly in one technical area (whether it be IDS-firewall-SEIM management, pen-testing, systems administration, etc) as well as one field of application (military, ICS, health care, payment, etc). They will know about the other areas, but not be experienced in them. They will also be older, which means they're more likely to have a family, which means they likely need to live near the business.
All of this adds up to restricting the pool of 'qualified' applications unnecessarily. The person who understands NIST compliance will pick up PCI DSS compliance fairly quickly. The person who can use Splunk will understand IBM Tivoli. If the person can do the job, they will be able to gain whatever certification is necessary.
Alternately, an organization could simply hire out of the body of skilled programmers and systems administrators and plan to train them in security. With some minor planning, this will provide much better employees anyway as you can ensure their skill set and most will enjoy the opportunity to improve their skills. Frankly, the industry moves so fast that you're going to be continuously training your infosec professionals anyway. Someone who has simply been the specialist in their area for years without continuous education is likely just as ready to take the job as a newcomer to infosec, regardless of what their resume says. What you really get with an experienced employee is maturity and acclimation to the business environment.
Management Problem 2: Getting them.
First, if you happened to have found the perfect person, they know it too. They will expect to be very well paid (regardless of how mundane the actual job is). Additionally, if the job description says you wanted an infosec deity yet your plan is to have them write firewall rules all day, they might not be amused. If you hire highly technical, highly skilled people, give them a broad, highly technical job. Give the firewall rule writing to an intern with a reference manual. Also, be mindful of your location. Do you really need the person on sight or would one week a month work? Most people either love or hate the urban environments of the coast. Finally, if you're the government, don't require clearances for everyone. There's a large portion of the infosec community who doesn't want to have a clearance. They are good, honest, professionals. They just don't want the obligations and hassle associated with a clearance. Additionally, be leaving defensive work as unclassified as possible, you make it available to industry who desperately needs it.
Management Problem 3: Keeping them.
So you gave a bunch of money to a rock star infosec professional. Or maybe you hired a young gun to become one of your infosec gurus. Like many things in life, they won't stay or be productive unless they are treated right. The very first step is to figure out what type of person they are. (Employers should have figured this out before they hired, but it can take some time.) Some people enjoy 'turning the crank'. They enjoy doing a somewhat repeatable job that has clear bounds. If that's the type of infosec professional you hired, best not to ask them to architect your infosec defense. Put them on change request review. Alternately, if they are a creative self-starter, asking them to predominantly push windows patches may not provide them a fulfilling work life. Regardless, most infosec professionals have some ideas about how things could be done better. listen and act on them! Clearly the status quo is not good enough. Implicitly that means new ideas will be required to get an acceptable infosec posture.
Second, provide a career, not just a job. Currently, infosec is about desperately needing to fill some niche in an organizations security team. This simply makes for pigeon-holed, unfulfilled, employees. The wealth of infosec training is absolutely necessary to help employees grow in their career (as well as simply maintain their proficiency). Additionally, there is a need to provide a career progression. The guy watching the SEIM at night should know where he will be promoted next if he does well. There should be tractability from his position to CISO with a list of necessary skills to move to the next level. Finally, as stated above, give your employees a chance to have their ideas assessed and supported. You hired them to solve problems. Listen to the solutions they provide. When you don't listen, people leave or simply give their ideas to someone else, (most likely github).
In Conclusion.
Any organization should be able to meet their security needs. They won't do it by hiring the perfect infosec professionals, but hiring an appropriate mix of creative thinkers and skilled crank turners, preparing them for the work the organization needs done, and then providing them rewards and career growth for accomplishing it. Until we realize infosec staffing is a management problem and not a labor force one, our information security will continue to lag.
Epilogue.
I do want to point out that most of these are not specific to infosec. Any seasoned manager will notice that these are general management concepts. They apply to almost any skilled labor force. That said, I think the mysticism behind computer security has caused us to go blind on infosec management. Organizations believe infosec is a type of voodoo that only an appropriate witch doctor can wield. Consequently, organizations forget everything they know about management and instead hand the entire operation (management and all) over to whoever their current chosen witch doctor is. Instead they should treat it as any other skilled profession. Good management will lead to good recruiting. No voodoo necessary.
The unavailability of infosec professionals is a manufactured shortage. It's controlled by many factors: specialization within information security, required certifications, fragmented compliance standards, required software qualifications, clearances, and job locations to name a few. Infosec, cybersec, or whatever you want to call it is one of the coolest yet most accessible STEM jobs available. There is a huge body of programmers, systems administrators, and technology professionals who would gladly work in infosec. No, what we have is a management problem.
Management Problem 1: Who we will hire.
If you are CYBERCOM, you want 4,000 qualified cyber security professionals. Except you want them in the Washington D.C. area with a TS/SCI clearance. If you are DHS, you still want them with a clearance as well as an arbitrary certification. If you are a business, you want them with broad infosec knowledge, experience on the tools you've bought, certification in your area of specialty, and experience in your specific compliance regimen. The frank fact is that deep experience is somewhat mutually exclusive with specialization in your business area. As anyone gains experience, they're going to have it mostly in one technical area (whether it be IDS-firewall-SEIM management, pen-testing, systems administration, etc) as well as one field of application (military, ICS, health care, payment, etc). They will know about the other areas, but not be experienced in them. They will also be older, which means they're more likely to have a family, which means they likely need to live near the business.
All of this adds up to restricting the pool of 'qualified' applications unnecessarily. The person who understands NIST compliance will pick up PCI DSS compliance fairly quickly. The person who can use Splunk will understand IBM Tivoli. If the person can do the job, they will be able to gain whatever certification is necessary.
Alternately, an organization could simply hire out of the body of skilled programmers and systems administrators and plan to train them in security. With some minor planning, this will provide much better employees anyway as you can ensure their skill set and most will enjoy the opportunity to improve their skills. Frankly, the industry moves so fast that you're going to be continuously training your infosec professionals anyway. Someone who has simply been the specialist in their area for years without continuous education is likely just as ready to take the job as a newcomer to infosec, regardless of what their resume says. What you really get with an experienced employee is maturity and acclimation to the business environment.
Management Problem 2: Getting them.
First, if you happened to have found the perfect person, they know it too. They will expect to be very well paid (regardless of how mundane the actual job is). Additionally, if the job description says you wanted an infosec deity yet your plan is to have them write firewall rules all day, they might not be amused. If you hire highly technical, highly skilled people, give them a broad, highly technical job. Give the firewall rule writing to an intern with a reference manual. Also, be mindful of your location. Do you really need the person on sight or would one week a month work? Most people either love or hate the urban environments of the coast. Finally, if you're the government, don't require clearances for everyone. There's a large portion of the infosec community who doesn't want to have a clearance. They are good, honest, professionals. They just don't want the obligations and hassle associated with a clearance. Additionally, be leaving defensive work as unclassified as possible, you make it available to industry who desperately needs it.
Management Problem 3: Keeping them.
So you gave a bunch of money to a rock star infosec professional. Or maybe you hired a young gun to become one of your infosec gurus. Like many things in life, they won't stay or be productive unless they are treated right. The very first step is to figure out what type of person they are. (Employers should have figured this out before they hired, but it can take some time.) Some people enjoy 'turning the crank'. They enjoy doing a somewhat repeatable job that has clear bounds. If that's the type of infosec professional you hired, best not to ask them to architect your infosec defense. Put them on change request review. Alternately, if they are a creative self-starter, asking them to predominantly push windows patches may not provide them a fulfilling work life. Regardless, most infosec professionals have some ideas about how things could be done better. listen and act on them! Clearly the status quo is not good enough. Implicitly that means new ideas will be required to get an acceptable infosec posture.
Second, provide a career, not just a job. Currently, infosec is about desperately needing to fill some niche in an organizations security team. This simply makes for pigeon-holed, unfulfilled, employees. The wealth of infosec training is absolutely necessary to help employees grow in their career (as well as simply maintain their proficiency). Additionally, there is a need to provide a career progression. The guy watching the SEIM at night should know where he will be promoted next if he does well. There should be tractability from his position to CISO with a list of necessary skills to move to the next level. Finally, as stated above, give your employees a chance to have their ideas assessed and supported. You hired them to solve problems. Listen to the solutions they provide. When you don't listen, people leave or simply give their ideas to someone else, (most likely github).
In Conclusion.
Any organization should be able to meet their security needs. They won't do it by hiring the perfect infosec professionals, but hiring an appropriate mix of creative thinkers and skilled crank turners, preparing them for the work the organization needs done, and then providing them rewards and career growth for accomplishing it. Until we realize infosec staffing is a management problem and not a labor force one, our information security will continue to lag.
Epilogue.
I do want to point out that most of these are not specific to infosec. Any seasoned manager will notice that these are general management concepts. They apply to almost any skilled labor force. That said, I think the mysticism behind computer security has caused us to go blind on infosec management. Organizations believe infosec is a type of voodoo that only an appropriate witch doctor can wield. Consequently, organizations forget everything they know about management and instead hand the entire operation (management and all) over to whoever their current chosen witch doctor is. Instead they should treat it as any other skilled profession. Good management will lead to good recruiting. No voodoo necessary.
Sunday, February 10, 2013
Defensive Construct Exchange Standard
It has come time to provide a standard for the transmission of information between defensive tools. I understand that this is not a unique endeavor, however all attempts to this point have been limited by a single approach, a set of attributes a construct must or should have.
Why do we need something else? First, this is not a new SIEM. This is not Arcsight, it's not Splunk, it's not CIF or ELSA. This is not an information structure. It's not STIX, VERIS, or Mandiant IOCs. If anything, it's similar to TAXII or IDMEF. However all of these approaches (and the many other existing approaches) have a primary flaw: they have structure. The fundamental issues it that no matter what tool we use, it will collect different data. We will have similar fields (URLs, IPs, etc) tool to tool, but each provides a slightly different construct with slightly different fields associated with each construct. This limits all but the most general indexing tools (such as Splunk or ELSA) from importing data without an importer designed specifically for that data (such as an Arcsight connector).
Also, basically all tools (other than Paterva's Maltego) take a database approach to storing data. While this still allows searching data to match specific patterns (such as IP address), it is less efficient as linkages are implied only by the existence of the pattern in a row with other data. Passing data as records may hide linkages that could otherwise be uncovered.
Why do we need something else? First, this is not a new SIEM. This is not Arcsight, it's not Splunk, it's not CIF or ELSA. This is not an information structure. It's not STIX, VERIS, or Mandiant IOCs. If anything, it's similar to TAXII or IDMEF. However all of these approaches (and the many other existing approaches) have a primary flaw: they have structure. The fundamental issues it that no matter what tool we use, it will collect different data. We will have similar fields (URLs, IPs, etc) tool to tool, but each provides a slightly different construct with slightly different fields associated with each construct. This limits all but the most general indexing tools (such as Splunk or ELSA) from importing data without an importer designed specifically for that data (such as an Arcsight connector).
Also, basically all tools (other than Paterva's Maltego) take a database approach to storing data. While this still allows searching data to match specific patterns (such as IP address), it is less efficient as linkages are implied only by the existence of the pattern in a row with other data. Passing data as records may hide linkages that could otherwise be uncovered.
How is this different? In the Defensive Construct Exchange Standard (DCES), we see constructs as a small graph (in the graph theory sense). All the fields in the construct are represented as nodes and the nodes are linked with edges (rather than with a predefined construct or record format as in most other tools). See the example below for a visual representation. Because of this, sending parties and tools may provide any set or subset of fields, whether it be ones defined in STIX, CybOX, IDMEF, Unified2, or one specific to their needs. Receiving parties may easily discard or replace portions of the format that are unimportant to them while adding their own information to the construct. I'll detail some of the uses of this approach below.
Whats the standard? Initially, the standard is as follows. I recognize that this is a very early approach and that working with tool builders, vendors, and stakeholders will be necessary to fully realize this standard:
- All discrete pieces of information within a construct will be given an individual node (in the graph theory sense). All nodes within the construct are a type of Attribute. The actual attribute Attribute will be stored as a tuple within the node's "Metadata" attribute.
- All nodes will be linked to a node containing a construct ID generated by the construct originator. (It will be recommended that those linking constructs into their own graphs generate a local construct ID so as to avoid conflicts within their graph.)
- The construct ID will be a child node of all Attributes within the construct.
- The nodes and edges will be represented in JSON. They will be transmitted in accordance with the JSON format outlined by the @gephi graph streaming project (Gephi graph streaming). In practice, all constructs should be transmittable as a grouping of 'add node' and 'add edge' messages, with the recipient deciding how to actually handle the information.
- Attributes within the construct may have their own Attributes. (I.E. A threat construct's location Attribute may have a 'confidence' Attribute. Also, Attributes within the construct may have a child attribute representing a Classification such as "company proprietary", "PII", etc.) (Note this is less of a rule of the standard as an explicit flexibility.)
What a great idea gabe! Can we see an example? The following construct is used as an example in the STIX format. In the STIX example, it represents a link within a phishing email. Using our new format, it could be visually represented as:
This would then be represented in JSON as:
{"an":{"A":{"label":"Construct From X","Class":"Attribute","Metadata":{"ID":<value>}}}}\r{"ae":{"1":{"source":"A","target":"B","directed":true}}}{"ae":{"2":{"source":"A","target":"C","directed":true}}}{"ae":{"3":{"source":"A","target":"D","directed":true}}}{"ae":{"4":{"source":"D","target":"C","directed":true}}}{"ae":{"5":{"source":"C","target":"B","directed":true}}}{"ae":{"6":{"source":"A","target":"E","directed":true}}}{"ae":{"7":{"source":"A","target":"F","directed":true}}}{"ae":{"8":{"source":"A","target":"G","directed":true}}}{"ae":{"9":{"source":"G","target":"F","directed":true}}}{"ae":{"10":{"source":"F","target":"E","directed":true}}}{"ae":{"11":{"source":"A","target":"H","directed":true}}}{"ae":{"12":{"source":"A","target":"I","directed":true}}}{"ae":{"13":{"source":"A","target":"J","directed":true}}}{"ae":{"14":{"source":"J","target":"I","directed":true}}}{"ae":{"15":{"source":"I","target":"H","directed":true}}}{"an":{"B":{"label":"URL","Class":"Attribute","Metadata":{"URL":<value>}}}}{"an":{"C":{"label":"DOMAIN","Class":"Attribute","Metadata":{"DOMAIN":<value>}}}}{"an":{"D":{"label":"WHOIS","Class":"Attribute","Metadata":{"WHOIS":<value>}}}}{"an":{"E":{"label":"DNS Query","Class":"Attribute","Metadata":{"DNS Query":<value>}}}}{"an":{"F":{"label":"DNS Record","Class":"Attribute","Metadata":{"DNS Record":<value>}}}}{"an":{"G":{"label":"DNS Record Type","Class":"Attribute","Metadata":{"Record Type":<value>}}}}{"an":{"H":{"label":"DNS Query","Class":"Attribute","Metadata":{"DNS Query":<value2>}}}}{"an":{"I":{"label":"DNS Record","Class":"Attribute","Metadata":{"DNS Record":<value2>}}}}{"an":{"J":{"label":"DNS Record Type","Class":"Attribute","Metadata":{"Record Type":<value2>}}}}
How will this approach be used? In the most basic sense, two tools or groups exchanging information can simply use this to exchange standard formats (such as an IDMEF message). Alternately, it could be easily databased by tools such as Splunk or ELSA, however neither of these approaches makes use of the strength of the format and instead simply provide backwards compatibility with previous approaches and workflows.
A better use would be to maintain threat and event data in a graph. Graphs can be stored in memory, in a standard RDB, in a graph database or in any of a number of formats. When a DCES construct arrives at the receiving tool, it will likely parse the information, drop information it is uninterested in, and add information (such as a local ID) that it finds useful. From there the construct can be stored, linked to the rest of the graph (based on common information such as a common IP, alert ID, or any information that is present in both the construct and the graph. This linkage may be permanent or temporary to allow searching of the graph for other related information. This is similar to adding information in a graph in Maltego.
Tool wise, the clear benefit is that once a single DCES handler has been defined, there is no need to adjust it based on different construct formats which it might receive. Therefore a tool or organization can share and receive a much larger and more diverse set of information. From an operational standpoint this allows more robust collection and definition of threat actor (and non-threat actor) information. It also allows new approaches to determining the reputation of an event, (i.e. is it a false positive or is it linked to other suspicious behavior).
We're on the cusp of mounting an effective information security defense and putting all the information our threats reveal about themselves to use. To do that though, we must not just be able to tune big SIEMS to accept a specific set of information, but must be able to aggregate all information and understand it's associations. This format is a step in that direction.
Antivirus is Dead. Long live Antivirus!
Anti-virus is an oft-maligned tool in infosec. It clearly mitigates some risks. It also clearly misses many risks. But the discussion often misses some important questions: What is AV? What role should it play in our infosec posture? How do we measure if it is doing its role?
Originally, anti-virus were simple signatures to detect viruses. Now, as Kurt Wismer points out in his blog (debating AV effectiveness with security experts), the term AV is used to describe multiple different types of technologies. There are signatures, heuristics, and, more recently, a pseudo-white list system. AV detects anomalies. AV detects malware. AV prevents malware execution. AV prevents non-executed malware from spreading. AV maintains a baseline of the system. AV may address viruses, worms, rootkits, botnet clients, phishing scams, adware, or any combination. It may monitor the network the file system, and/or specific services such as http or email. AV has become a catch-all, defining almost any host-based technology. Because it is ingrained in even non-infosec minds that AV is necessary, everything is now AV.
However, this ubiquity prevents AV from being effectively incorporated into an overarching infosec strategy. How can we possibly hope to use AV to do a specific job when it could potentially be doing so many jobs? I've blogged previously (The Chicken and the Pig - Three Security Genres) on the different roles in information security. AV straddles those responsibilities. AV could be an integral part of your detection. It could be part of your defensive prevention. It could be used to deal with phishing attacks, untargeted self-propagating malware, drive-by web attacks, or strict white-listing of all code run on hosts. It could be used to simply weed out general attacks or an attempt to stay abreast of the most modern, evolving attacks.
AV is not a catch-all. Just because the name covers multiple technologies does not mean that buying it covers you in so many different ways. So what is a company to do? Specific AV capabilities must be identified and targeted at specific company needs:
- Understand what assets you have to protect and what threats you face. You can take no action on your infosec posture without knowing this.
- Understand what technology is incorporated in the AV you have deployed (or are considering deploying). Understand in real terms what threats the AV is designed to address. What is it expected to detect? What is it expected to block? More importantly, what will it not detect and block?
- What other technologies or means do you have to address the gaps in your AV?
- Are the AV's capabilities redundant with capabilities you already have?
Measuring the effectiveness of AV is an area where research is needed. While there are ways to measure it, they are not particularly targeted at any specific capability of the AV, nor are they targeted at any specific threat actor (or asset to protect). As we start to understand and articulate the individual technologies and capabilities provided by AV, we can align them to threat actor types and provide effective measures which explain what type of return on investment can be expected from deploying a specific AV tool in a specific scenario to protect a specific asset from a specific threat. Also, these metrics should have their temporal properties measured as all attacks and defenses happen over time.
It's time for AV to evolve, not necessarily technologically, but in our consciousness. It can no longer be a generic catch-all for things that sit on host. Instead, the specific technologies and capabilities need to be promoted so that they can be applied as a clear part of an infosec posture rather than a generic Band-Aid.
Monday, April 2, 2012
We Need Better Defensive Tools
We Need Better Defensive Tools
Period. The tools we have right now are basic, non-interoperable, and non-granular. There is no Metasploit framework for defense. Let me paint a picture of a particular aspect - intel:
Current State
Many times after a security breach, we see a web of interactions between domains, malicious tools, C&C servers, personal information (email addresses, names, aliases), etc.
The Dell analysis of the RSA breach is one example (http://www.secureworks.com/research/threats/sindigoo/). These webs all seem to be manually generated after-the-fact.
Where We Should Be
Why couldn't we generate a significant amount of this in an automated fashion? Using Mandiant IOCs, IP reputation lists, or other intel feeds as well as the data from our own networks should let us build a very robust web of malicious activity. This web can help us identify the reputation and actor behind an event (packet, netflow, higher level interaction) we observe on our networks.
Let's say you start with a database of Mandiant IOCs and suspicious IPs from updated Snort rules. We are collecting the regular information from HIDS, NIDS, AV, Netflow, SNMP, Syslog, etc. We compare the information we get to our database and something matches (an IP/domain, the attack vector, the malware, etc). We now have a point connecting the event to our intelligence web.
Through the web we identify domains associated with the malware and scrape the domain for information. The scrape pulls up multiple executables which are identified as malicious. A Google search for the domain turns up posts linking personal information to the domain.
A Whois search turns up other associated domains. This can then all be fed into the web stored in the database to improve it. At the same time, we know at some level of confidence whether the event can be attributed to an attacker we know of.
Now What
The next step is to automate the response. (This is the same as your bank calling you when your credit card is used on the other side of the country or Facebook throttling your ability to send messages.)
You can attribute an event to an attacker, and that attacker can have a response associated with them: (throttle them, block them, redirect to a honeypot, etc). The response could be implemented automatically or with a human in the loop.
The end result is, based on your intelligence web, you degraded service to an attacker and collected more information to better identify them the next time they attack. All with minimal work on your part.
Nothing about this is revolutionary. Marketers, Google, Facebook, etc are all able to piece information together to identify you even when you don't explicitly say who you are. Banks, online video games, and major web services all degrade service based on perceived threats. It's simply time for infosec defense to step into the modern world.
Prologue
I've left many things out above to keep the post clear. However, There is certainly more to this idea once you start thinking more about it.
The first is existing tools. Mandiant OpenIOC, Verizon VERIS, Microsoft Threat Intelligence Feed, Snort VRT rules, Maltego, Incident Object Description and Exchange Format, I could go on. I think we are getting to where we have both robust sources of intelligence as well as formats and frameworks to describe them. What we lack is away to make them actionable.
The first is existing tools. Mandiant OpenIOC, Verizon VERIS, Microsoft Threat Intelligence Feed, Snort VRT rules, Maltego, Incident Object Description and Exchange Format, I could go on. I think we are getting to where we have both robust sources of intelligence as well as formats and frameworks to describe them. What we lack is away to make them actionable.
Most of the above tools/frameworks are incompatible and many aren't even actionable except manually. We lack a single intel data storage tool that can be extended to accept whatever formats are available. (Or if we have one, we're certainly not using it.)
Additional the tool needs to be extendable to facilitate response and remediation. Making response a manual effort is a losing battle when offense is push-button easy.
Another issue is sharing. We all have intel that would be helpful but that we, frankly, are not allowed to share. That's ok. If the tool is flexible, we will all join the circles of sharing we are allowed in to. Corporations can run their own sharing groups, choosing who's in and who's out.
Industries can choose to share with each other. Some intel feeds might be available to everyone. Some organizations may even choose to provide access to their web as a service. You submit an event. They reply with associations, keeping the actual web private.
And let's not forget the benefits. Because your defense improves every time you are attacked, you have raised the cost of attacking. Every failed attack makes the next attack more likely to fail. That means, to be successful, attacks must be of higher quality which means they cost more resources. Because they cost more, minor threats are priced out of the market.
Repeat attackers will have an even harder time. They will need to stage completely from scratch for every attack. Different domains, IPs, tools, browser headers, email address, attack times of day, everything. Otherwise they risk being associated with the web and having all of what they DID change associated with their profile.
The flexibility to start from scratch requires a large amount of skill which again prices many attackers out of the market. It's time. Let's build the tools to bring our intel together to execute a better defense.
(Cross posted at https://www.infosecisland.com/blogview/20880-We-Need-Better-Defensive-Tools.html)
(Cross posted at https://www.infosecisland.com/blogview/20880-We-Need-Better-Defensive-Tools.html)
Friday, January 13, 2012
On Defending Networks
I just read Military Networks ‘Not Defensible,’ Says General Who Defends Them at Wired.
In the article, he repeats a subtle point that I've heard from him before, "Defend the network".
This is a critical distinction from "build the network securely". It shows an understanding that engineering is only a supporting step in defending the network (as I blogged about here).
However he still seems to be concerned with planning the battle. No war is won by planning a battle. Wars are won by FIGHTING.
I don't mean to understate the importance of planning. It can probably never be overstated. However, if you're already in the battle, fighting back is critical to providing the chance to do that planning.
If a soldier is told to take a hill, he takes it, (I assume, not having ever been in the military).
More so, he is trained to do that. He is taught to assess the hill, figure out the best defense for the situation, (no matter how good or bad the situation is), and execute it.
The same needs to be applied to our networks.
If we can secure areas of the world existing in at least 3 domains (land, air, and space) if not four (adding sea), then we should easily be able to train to defend networks existing in a single domain (digital).
If we can secure a spot of land which has an infinite number of paths in and out, then we should be able to train to defend a network defined digitally.
In fact, the only disadvantage to the digital domain is the speed at which conflict executes within it.
Is the defense harder than it has to be? Absolutely. Do we gain by going back and re-engineering the digital terrain to be more defendable? Yes.
However, the second step is jumping on the network, mapping it out, planning a defense, and executing it (as I talked about here). The first step is training and equipping people to do so.
(Cross posted at https://www.infosecisland.com/blogview/19348-On-Defending-Networks.html)
(Cross posted at https://www.infosecisland.com/blogview/19348-On-Defending-Networks.html)
Subscribe to:
Posts (Atom)