The CISO’s Guide to Advanced Attacks: Intelligence, the Crystal Ball of Security

As discussed in our first post in the CISO’s Guide to Advanced Attackers, the first step is to determine what kind of attack would have the greatest impact on your environment (most likely mission), so you can infer which kinds of adversaries you are likely to face. Armed with context on likely adversaries, we can move into the intelligence gathering phase. This involves learning everything we can about possible and likely adversaries, profiling probable behaviors, and determining which kinds of defenses and controls make sense to address the higher probabilities. As we mentioned when wrapping up the last post, at the end of the day these are all just educated guess. That’s why we keep using the word likely. But these guesses can be very useful for a head start on detect advanced attacks. When you are racing the clock with an adversary in your environment that head start can make the difference in whether key data is exfiltrated. Master the Basics But first there iss something we neglected in the introductory post, the importance of a strong set of security controls in place at the start of the process. Dealing with advanced attackers is not for unsophisticated or immature security organizations. The first order of business is to pick the low hanging fruit, and ensure you aren’t making it easy for attackers. What does that mean? You need to master the basics and have good security practices implemented. We will not go into detail here – you can check out our research library for chapter and verse on security practices. Before you can address advanced attacks, you need to have already hardened key devices, implemented a strong hygiene (patch and configuration management) program, and properly segmented your network to make it difficult for attackers to get at important data. We can laugh about the futility of traditional endpoint protection, but you still need some measure of protection on key devices with access to sensitive data. For the rest of this series we will assume (and yes, we know the hazards of assuming anything) that you are ready to deal with an advanced attacker – meaning you have a relatively mature security program in place with proper control sets. If you can’t make that kind of statement, go do that now, and you can resume reading this paper once you’re done. Profiling the Adversary For better or worse, the industry seems to believe that intelligence = “threat intelligence.” And the many organizations not doing much to shorten the detection cycle for advanced attacks can get away with this generalization. But threat intelligence is a subset of intelligence – to really understand your adversaries you need to go deeper than learning the indicators of compromise found in their last attack. That means you will want to learn what they do, how they do it, where they live, what they like to do, where they were trained, the tools they use, the attacks they have undertaken, the nuances of their attack code, and their motives. Yes, that is a big list, and not many organizations are in a position to gather this kind of real intelligence on adversaries. You can check out some of the publicly available information in the APT1 report, which provide unprecedented detail about these apparently state-sponsored Chinese hackers to get a feel for the depth of intelligence needed to seriously combat advanced attackers. In light of the reality of limited resources and even more limited intelligence expertise, you are likely to buy this kind of intelligence or get it from buddies who have more resources and expertise. You can gather a lot of intelligence by asking the right questions within your information sharing community or talking to researchers at your strategic information security vendors. Depending on how the intelligence is packaged, you may pay or get the ability to interact with their security researchers as part of your product/service agreement. The kind of adversary intelligence you need goes well beyond what’s published in the quarterly threat reports from all the security vendors. They tend to give away their least interesting data as bait, but they are very likely to have much more interesting data which use they for their own work – you just have to ask and possibly subscribe to get access. When we talk about how advanced attackers impact the security process at the end of this series, we will discuss how to integrate this type of adversary intelligence into your security program. Threat Intelligence Indicators Now that we have defined the intelligence terminology we can get into the stuff that will directly impact your security activity: the threat intelligence that has become such a hot topic in security circles. We have recently researched this topic extensively so we will highlight a bunch of it here, but we also recommend you read our papers on Building an Early Warning System, Network-based Threat Intelligence, and Email-based Threat Intelligence for a much deeper look at the specific data sources and indicators you will be looking for. But let’s start with a high-level overview of the general kinds of threat intelligence you are likely to leverage in your efforts to deal with advanced attackers. Malware Malware analysis is maturing rapidly, and it is becoming common to quickly and thoroughly understand exactly what a malicious code sample does and define behavioral indicators you can search for within your environment. We described this in gory detail in Malware Analysis Quant. For now suffice it to say that you aren’t looking for a specific file – that would just take us back to AV blacklists – instead you will seek indicators of what a file did to a device. Remember, it is no longer about what malware looks like – it is now about what it does. Fortunately a number of parties offer information services that provide data on specific pieces of malware. You can get an analysis based on a hash of a malware file, or upload a file that hasn’t been seen before. The services run malware samples through a sandbox to figure out what it does, profile it, and

Read Post

Run faster or you’ll catch privacy

One of the things that smacked me upside the head at a recent IANS Forum, where I run the CISO track, is the clear merging of the security and privacy functions under the purview of one executive. Of the 15 or so CISOs in the room, at least half also had responsibility for privacy. And many of them got this new responsibility as part of a recent reorganization. So once again be careful what you wish for. It was a lot more fun to be able to rail at the wacky privacy folks working for the CFO or General Counsel, wasn’t it? Not so much now that it’s your problem. To be fair this evolution is logical – you cannot really separate out the two if you accept that it’s all about protecting customers. Not only do you have to keep customer data private, but you could make the case that protecting intellectual property ensures you can deliver value to those customers. Malcolm Harkins, CISO (and now CPO) of Intel appeared on a podcast to explain why his organization recently gave him responsibility for the privacy function as well. Intel has added privacy to the portfolio of its top information security executive, Malcolm Harkins, who says too many information security professionals are “color blind or tone deaf” to privacy, wrongly thinking strong data protection provides privacy safeguards. Most security types didn’t want to deal with the policies and other squishy things privacy folks must deal with. It was easier to focus on technology and leave the softer stuff to other folks. We don’t have that choice any more, and if you’re at the CISO level and still largely focused on technology, you’re doing it wrong. But if you thought responsibility for privacy wasn’t bad enough, a few CISOs are now taking on responsibility for management of building access systems as well (as part of physical security), as they are increasingly integrated with existing IAM systems. The fun never ends… Photo credit: “Privacy” originally uploaded by PropagandaTimes Share:

Read Post

Intel Buys Mashery, or Why You Need to Pay Attention to API Security

Intel acquired API management firm Mashery today. readwrite enterprise posted a very nice write-up on how Mashery fits into the greater Intel strategy: Intel is in the midst of a shift away from just selling chips to selling software and services. This change, while little-noticed, has been long in the making. Intel bought McAfee for $7.7 billion in 2010, putting it into the security-software business. In 2005, Intel bought a smaller company, Sarvega, which specialized in XML gateways. (XML, or extensible markup language, is a broad descriptor of a file format commonly used in APIs; an XML gateway transports files to make APIs possible.) Ideally, Intel might sell the chips inside the servers running the software programs that communicate via these APIs, too. (It has a substantial business selling such chips.) But what’s more important is the notion that Intel has a product offering that speaks to innovative startups, not just struggling PC manufacturers. With the shift in the market from SOAP to REST over the last several years, and the explosion of APIs for just about everything, especially cloud and web services, tools like Mashery help both with the transformation and with gluing all the bits together. Because you can decide which bits of the API to expose and how, Mashery is a much more services-oriented way to manage which features – and what data – are exposed to different groups of users. It is an application-centric view of security with API management as the key piece. Stated another way, Intel is moving away from the firewall and SSL security model we are all familiar with. Many in the security space don’t see Intel as a player, despite its acquisition of McAfee. But Intel has been quietly developing products for tokenization, identity services, and security gateways for some time. Couple that with API security, and you start to get a clear picture of where Intel is headed – which is distinctly different than what McAfee offers for endpoints and back offices today. Share:

Read Post

On password hashing and how to respond to security flaws

I have been learning a lot lately about password hashing since we realized our own site used an inadequate mechanism (SHA256). I am also a major fan of 1Password for password generation and management. So I held my breath while reading how to use Hashcat on 1Password data: The reason for the high speed is what I think this might be a design flaw. Here is why: But if you take a close look now you see these both mechanisms do not match in combination. To find out if the masterkey is correct, all we need is to match the padding, so all we need to satisfy the CBC is the previous 16 byte of data of the 1040 byte block. This 16 byte data is provided in the keychain! In other words, there is no need to calculate the IV at all. I have an insanely long random master password, so this isn’t a risk for me (it sucks to type on my iPhone), but it’s darn creative and interesting. The folks at AgileBits posted a great response in the comments. Rather than denying the issue, they discussed the risk around it and how they already have an alternative because they recognized issues with their implementation: I could plead that we were in reasonably good company in making that kind of error, but as I’ve since learned, research in academic cryptography had been telling people not to use unauthenticated encryption for more than a decade. This is why today we aren’t just looking at the kinds of attacks that seem practical, but we are also paying attention to security theorems. In other words, they owned up and didn’t deny it, which is what we should all do. For more details, read this deeper response on the AgileBits site. It’s worth it for a sense of these password hashing issues, which are something all security pros need to start absorbing. Share:

Read Post

Safari enables per-site Java blocking

I missed this during all my travels, but the team at Intego posted a great overview: Meanwhile, Apple also released Safari 6.0.4 for Mountain Lion and Lion, as well as Safari 5.1.9 for Snow Leopard. The new versions of Safari give users more granular control over which sites may run Java applets. If Java is enabled, the next time a site containing a Java applet is visited, the user will be asked whether or not to allow the applet to load, with buttons labeled Block and Allow: Your options are always allow, always block, or prompt. I still highly recommend disabling Java entirely in all browsers, but some of you will need it and this is a good option without having to muck with plugins. Share:

Read Post

No news is just plain good: Friday Summary, April 18, 2013

I know the exact moment I stopped watching local news. It was somewhere around 10-15 years ago. A toddler had died after being left locked in a car on a hot day. I wasn’t actually watching the news, but one of the screamers for the upcoming broadcast came on during a commercial break for whatever I was watching. A serious looking female reporter, in news voice, mentioned the death and how hot cars could get in the Colorado sun. Then she threw a big outdoor thermometer in a car, slammed the door, and reminded me to watch the news at 10 to see the results. I threw up a little bit, I think. I don’t remember the exact moment I gave up on cable news, but it was sometime within the past year or two. I have a TV in my office I use for background noise; one of those little things you do when you have been working at home for a decade or so. I used to keep it on MSNBC but the bias finally went too over the top for me. Fox is out of the question, and I was trying out CNN. That lasted for less than an hour before I realized that Fox is for the right, MSNBC for the left, and CNN for the stupid. It was nothing other than sensational exploitative drivel. As an emergency responder I know what we see at night rarely correlates to actual events. I have been on everything from national incidents to smaller events that still attracted the local press. Even responders and commanders don’t always have the full picture – never mind a reporter hovering at the fringe. Once I was on the body recovery of a 14-year-old who died after falling off a cliff while taking a picture. I showed up on the third day of the search, right around when one of our senior members finally located him due to the green gloss of a disposable camera. He used a secondary radio channel to report his location and finding because we know the press scans all the emergency frequencies. I was quietly sent up and we didn’t stop the rest of the search, to provide a little decorum. Around the time the very small group of us arrived at the scene, the press finally figured it out. The next thing I knew there was a helicopter headed our way to get video. Of a dead kid. Who had been in the Colorado sun, outdoors, for 3 days. I used my metallic emergency blanket to cover him him and protect his family. Years later I was on another call to recover the body of a suicide in one of the most popular mountain parks in Boulder. Gunshot to the head. When we got to the scene one of the police investigators mentioned we that needed to watch what we said because the local station had a new boom mike designed to pick up our conversations at a distance. I never saw it, so maybe it wasn’t true. I don’t watch local news. I don’t watch cable news. Even this week I avoid it. They both survive only on exploitation and emotional manipulation. I do occasionally watch the old-school national news shows, where they still behave like journalists. I read. A lot. Sources with as little bias as I can find. According to the Guardian, research shows the news is bad for you. Right now I find it hard to disagree. On to the Summary: Favorite Securosis Posts Adrian Lane: Run faster or you’ll catch privacy. Managing privacy in large firms is its own private hell. Hello, EU privacy laws! Mike Rothman: Sorry for Security Rocking. LMFAO applied to security FTW. And evidently I slighted our contributor Gal, who believes he’s up to provide the definitive Security LMFAO version. Name that tune, brother! Rich: The CISO’s Guide to Advanced Attacks. I am jealous I’m not writing this one. David Mortman: Run faster or you’ll catch privacy Other Securosis Posts Intel Buys Mashery, or Why You Need to Pay Attention to API Security. On password hashing and how to reply to security flaws. Safari enables per-site Java blocking. Incite 4/17/2013: Tipping the balance between good and evil. Why you still need security groups with host firewalls. Is it murder if the victim is already dead?. Unused security intelligence is, well… dumb. Favorite Outside Posts Adrian Lane: Agilebits 1Password support and Design Flaw?. Good discussion of the flaw and a good response from AgileBits. Now… patch, please! Mike Rothman: Patton Oswalt on the Boston Marathon Attack. I linked to this in the Incite but it’s worth mentioning again. Great context about taking a long-term view, even when the wounds are fresh. David Mortman: NIST: It’s Time To Abandon Control Frameworks As We Know Them. Rich: EmergentChaos on the 1Password design flaw issue. Don’t just read the post – read the first comment. The guys at AgileBits show yet again why I trust them. Research Papers Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Top News and Posts ColdFusion hack used to steal hosting provider’s customer data. Wait, people still use Cold Fusion? (Rich – I used to totally rock CF, back in the day!) Oracle Patches 42 Java Flaws. House approves cybersecurity overhaul in bipartisan vote. Cloudscaling licenses Juniper virty networking for new OpenStack distro. Microsoft deploys 2-factor to all services. Obama threatens to veto CISPA. Get your popcorn. Update: DARPA Cyber Chief Peiter “Mudge” Zatko Heads To Google. Google does so many great security things, but their views on privacy kill their usefulness to me. Blog Comment of the Week This week’s best comment goes to fatbloke, in response

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.