Securosis

Research

Token Vaults and Token Storage Tradeoffs

Use of tokenization continues to expand as customers look to simplify PCI-DSS compliance. With this increased adoption comes a lot of vendor positioning and puffery, as they attempt to differentiate their products in an increasingly competitive market. Unfortunately this competitive positioning often causes confusion among buyers, which is why I have spent the last couple mornings answering questions on FPE vs. Tokenization, and the difference between a token vault and a database. Lately most questions center on differentiating tokenization data vaults, with the expected confusion caused by vendor hyperbole. In this post I will define a token vault and shed some light on their pros and cons. My goal is to help you determine as a consumer whether vaults are something to consider when selecting a tokenization solution. A token vault is where you store issued tokens and the credit card numbers they represent. The storage location is called a “token vault”. The vault typically contains other information, but for this discussion just think of the token vault as a long list of CC#/token pairs. A new type of solution called ‘stateless’ or ‘vault-less’ tokenization is now available. These systems use derived tokens, which can be recalculated from some secret value, and those do not need to be stored in a database. Recent press hype claims that token vaults are bad and you should stay away from them. The primary argument is “you don’t want a relational database as a token vault” – or more specifically, “an Oracle database makes a slow and expensive token vault, and customers don’t want that”. Not so fast! The issue is not clear-cut. It’s not that token vaults are good or bad, but of course there are tradeoffs. Token vaults are fine for many types of customers, but not suitable for others. There are three issues at the heart of this debate: cost, scale, and performance. Let’s take a closer look at each of them. Cost: If you are going to use an Oracle, IBM DB2, or Microsoft SQL Server database for your token vault, you will need a license for the database. And token vaults must be redundant so you will need at least a couple licenses. If you want to ensure that your tokenization system can handle large bursts of transactions – such as holiday shopping periods – you will need hefty servers. Databases are priced based on server capacity, so these licenses can get very expensive. That said, many customers running in-house tokenization systems already have database site licenses, so for many customers this is not an issue. Scale: If you have data processing sites where token servers are dispersed across remote data centers that cannot guarantee highly reliable communications, synchronization of token vaults is a serious issue. You need to ensure that credit cards are not misused, that you have transactional consistency across all locations, and that no token is issued twice. With ‘vault-less’ tokenization synchronization is a non-issue. If consistency across a scaled tokenization deployment is critical derived tokens are incredibly attractive. But some non-derived token systems with token vaults get around this issue by pre-allocating token sequences; this ensures tokens are unique, and synchronization latency is not a concern. This is a critical advantage for very large credit card processors and merchants but not a universal requirement. Performance: Some token server designs require a check inside the token vault prior to completing every transaction, in order to ensure to avoid duplicate credit cards or tokens. This is especially true when a single token is used to represent multiple transactions or merchants (multi-use tokens). Unfortunately early tokenization solutions generally had poor database architectures. They did not provide efficient mechanisms of indexing token/CC# pairs for quick lookup. This is not a flaw in the databases themselves – it was a mistake made token vault designers as they laid out their data! As the number of tokens climbs into the tens or hundreds of millions, lookup operations can become unacceptably slow. Many customers have poor impressions of token vaults because their early implementations got this wrong. So very wrong. Today lookup speed is often not a problem – even for large databases – but customers need to verify that any given solutions meets their requirements during peak loads. For some customers a ‘vault-less’ tokenization solution is superior across all three axes. For other customers, with deep understanding of relational databases… security, performance, and scalability are just part of daily operations management. No vendor can credibly claim that databases or token vaults are universally the wrong choice, just like that nobody can claim that any non-relational solution is always the right choice. The decision comes down to the customer’s environment and IT operations. I am willing to bet that the vendors of these solutions will have some additional comments, so as always the comments section is open to anyone who wants to contribute. Share:

Share:
Read Post

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

Share:
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:

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:

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:

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:

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

Share:
Read Post

Incite 4/17/2013: Tipping the balance between good and evil

There are things you just can’t explain. No amount of dogma, perceived slights, or anything can excuse a senseless act of violence on unsuspecting, innocent people. Yes, I’m talking about the Boston Marathon attack, but it applies extends to any act of terrorism. I believe in karma, and the perpetrators will get their just rewards. Maybe out of the view of the public eye, but they will. Though I’m not really a fan, Schneier has it right in his post, “Keep Calm and Carry On”. We cannot live in fear. That’s what the terrorists want. We can’t legitimize their cause and we can’t impinge on our personal freedoms. Because then they win. Truth be told, we in the US are spoiled. There are many parts of the world where a bombing like yesterday wouldn’t even make the news. Where terror is an everyday occurrence. I feel very fortunate that isn’t my life and it’s not the life of my kids. We won the birthplace lottery and we must not forget that. But we do have to deliver some kind of message to the younger generation. Try to explain the unexplainable. In today’s iPhone (and iPod touch) driven society, the kids are tuned in whether we like it or not. XX1’s Instagram blew up with pictures and prayers, and she started asking questions right when she got home from school. XX2 and the Boy learned of it soon after because news travels like wildfire in my house. All we could do is explain that some people are misguided souls and they harm each other for no apparent reason. We are security folks. We understand how this works. That you can be aware of what’s around you and not put yourself unnecessarily at risk, but you cannot eliminate this kind of attack. Schneier mentions (correctly) your extreme unlikelihood of being personally impacted by this kind of attack. That’s little consolation to my friend who was at the finish line yesterday, who still has a ringing in his ears and concussive effects from the explosion. And it’s clearly no consolation to the families the people hurt in the attack, picking up the pieces of their lives today. But ultimately the balance is tipped heavily towards the good. Just think of the emergency responders running into the blast area. The folks carrying the wounded out of harm’s way. People opening their homes to displaced strangers. Good people doing good deeds when called upon. The best viewpoint I saw yesterday came from comedian Patton Oswalt on Facebook. He makes exactly the right point at exactly the right time: But the vast majority stands against that darkness and, like white blood cells attacking a virus, they dilute and weaken and eventually wash away the evil doers and, more importantly, the damage they wreak. This is beyond religion or creed or nation. We would not be here if humanity were inherently evil. We’d have eaten ourselves alive long ago. So when you spot violence, or bigotry, or intolerance or fear or just garden-variety misogyny, hatred or ignorance, just look it in the eye and think, “The good outnumber you, and we always will.” Well said, Mr. Oswalt. Well said. –Mike Photo credits: good and evil originally uploaded by Scotto Bear Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. The CISO’s Guide to Advanced Attackers Sizing up the Adversary Understanding Identity Management for Cloud Services Buyers Guide Architecture and Design Integration Newly Published 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 Incite 4 U Can we sacrifice PCI yet? Dave Elfering makes a number of good points in Worshipping at the Alter of Best Practices. It is basically stuff you know, but we see folks fall into the same trap over and over again. Not you but other folks, of course. Looking for the prescriptive guidance rather than doing the work. “Unfortunately we in security and IT often succumb to the microwave dinner approach to solving business issues.” Should we call this the Hungry Man approach to security? But Dave is exactly right – mandates start in the right place, but ultimately “often cross over into zealotry complete with dueling and echelons of priestly orders.” How many of you will be at the Temple of Bob Russo on Sunday? Yeah, that’s a scary thought… – MR Cloud FUD-tastic: Things must be getting ugly in the competitive battle between cloud vendors if Verizon is pulling out the FUD card by claiming that you’re ‘endangering’ your business by selecting Amazon as a cloud service provider. Many data centers did get flooded by hurricane Sandy, so Verizon’s dodging of that bullet makes them look smart by comparison, but that is a long way from claiming Amazon AWS endangers your business. Any cloud provider basing their competitive claims on 100% uptime is likely to be embarrassed in the future – it is unreasonable to expect a cloud service to be 100% reliable. And if Amazon AWS is having more security issues that competitors, I am willing to bet tha it’s because they have a lot more customers, with a far larger number who don’t take security seriously. If other cloud infrastructure providers want to cast stones, look at issues of lock-in and why more customers don’t have failover contingencies to multiple regions. Those are more compelling concerns. – AL Awareness and security training – not mutually exclusive: This is wading into the discussion a couple weeks late, but two of the biggest windbags in security, Bob Schneier and Ira Winkler, got into it over security training. Stephen Cobb provided a good summary and better perspective on the issues. Suffice it to say we need more and better of both security awareness

Share:
Read Post

The CISO’s Guide to Advanced Attackers: Sizing up the Adversary [New Series]

Every year there seems to be a new shiny object that works security marketeers into a frenzy. The Advanced Persistent Threat hype continues to run amok 3 years in, and doesn’t seem to be abating at all. Of course there is still lot of confusion about what the APT is, and Rich’s post from early 2010 does a good job explaining our view. That said, most security vendors are predictable animals and they adhere to the classic maxim “If all you have is a hammer, everything looks like an APT.” So it makes no difference what the security product or service does – they are all positioned as the answer to APT. Of course this isn’t useful to security professionals who actually need to protect important things. And it’s definitely not helpful to Chief Information Security Officers (CISOs) who have to communicate their organization’s security program and set realistic objectives, and manage expectations accordingly. So, as usual, your friends at Securosis will help you focus on what’s important and enable you to wade through the hyperbole to understand what’s hype and what’s real, in our new series: The CISO’s Guide to Advanced Attackers. This series will provide a high-level view of these “advanced attacks”, designed to help a CISO-level audience understand what they need to know, and map out a clear 4-step process for dealing with advanced attackers and their techniques. Before we get started I want to thank Dell SecureWorks for agreeing to potentially license the content at the end of the project. As with all our research, we will produce The CISO’s Guide to Advanced Attackers independently and objectively, and tell you what you need to know. Not what any vendor wants you to hear. Defining Advanced Attacks First let’s dismiss the common belief that advanced attackers always use “advanced attacks”. That’s just not the case. Of course there are innovative attacks like Stuxnet, stealing the RSA token seeds to attack US Defense sector organizations, and compromising Windows Update using stolen Certificate Authority signing keys. But those attacks are exceptions, not the rule. These attackers are very business-like in their operations. They don’t waste a fancy advanced attack unless they need to. They would just as soon get an unsuspecting office worker to click a phishing email and subsequently use a known Adobe Reader exploit to provide the attacker with a presence in your environment. There is no award for unique attacks. This understanding necessarily changes the way you think about adversaries. The attacks you see will vary greatly depending on the attacker’s mission and their assessment of the most likely means to compromise your environment. A better way to get your arms around potential advanced attacks is to first understand the potential targets and missions. Then profile specific attackers, based on their likelihood of be interested in the target. This can give you a feel for the tactics you are likely to face, and enables you evaluate controls that may be able to deter them – or at least slow them down. The security industry would have you believe that implementing a magic malware detection box on your perimeter or locking down your endpoints will block advanced attackers. Of course you cannot afford to believe everything you hear at a security conference, so let’s break down exactly how to determine what kind of threat you are facing. Evaluate the Mission Having the senior security role in an organization (yes, Mr./Ms. CISO, we’re talking to you) means accepting that the job is less about doing stuff and more about defining the security program and evangelizing the need for security with senior management and peers. A key first part of this process is to learn what’s important in your environment, which would be an interesting target for an advanced attacker. Since you have neither unlimited resources nor the capabilities to protect against every attack, you need to prioritize your defenses. Prioritize by focusing on protecting your valuables. The first order of business in dealing with advanced attackers is to understand what they are likely to look for. That is most likely to your: Intellectual property Customer data (protected) Business operations (proposals, logistics, etc.) Everything else It is unlikely that you can really understand what’s important to your organization by sitting in your office. So a big part of this learning requires talking to senior management and your peers to get a feel for what’s important to them. After a few of these conversations it should be pretty clear what’s really important (meaning people will get fired if it’s compromised) and what’s less important. Once you understand what the likely targets of an advanced attacker (the important stuff), you can take a reasonably educated guess at the adversaries you’ll face. Profile the Adversary We know it seems a bit simplistic to make generic assumptions about the kinds of attackers you will face, depending on what you are trying to protect. And it is simplistic, but you need to start somewhere. So let’s quickly describe a very high-level view of the adversaries you could face. Keep in mind that many security researchers (and research organizations) have assembled dossiers on potential attackers, which we will discuss with threat intelligence in the next post. Unsophisticated: These folks tend to smash and grab attacks, where they use a publicly available exploit (perhaps leveraging tools like Metasploit) or some kind of packaged attack kit. They are opportunistic and will take what they can get. Organized Crime: A clear step up the food chain is organized crime attackers. They invest in security research, test their exploits, and have a plan to exfiltrate and monetize what they find. They are still opportunistic, but can be quite sophisticated in attacking payment processors and large-scale retailers. They tend to be most interested financial data, but have also been known to steal intellectual property if they can sell it and/or use brute force approaches like DDoS threats to extort victims. Competitor: At times competitors use unsavory means to gain advantages in product development, or when seeking information on competitive bids. These folks

Share:
Read Post

Why you still need security groups with host firewalls

Security groups are the basic firewall rules associated with instances in various compute clouds. Different platforms may use different names but security group is the most common so that’s the term we will use. Basically, it is a way of defining hypervisor firewall rules. Of course this is a gross simplification – different cloud platforms enforce groups at other layers of the virtual or physical network, but you get the point. You assign instances to a security group and they inherit that rule set, which applies at a per instance level. This is key because you need to do some deeper thinking about what access rules should apply to an individual instance, which is distinctly not like a network segment with a firewall in front of it. For example you can set security group rules that restrict traffic between all instances assigned to the same security group. Thus it has traits of both a host firewall and network firewall, which is kinda cool. I was teaching our cloud security class last week and one student asked why we don’t just use IP tables or another host firewall. The answer is pretty basic. Security groups allow you to decouple network security from the operating system on the instance. This provides a few advantages: Security for specific instances can be managed without needing to instantiate or access them. Network security rules can be managed via the cloud API and management plane, supporting better automation. Security groups apply no matter the boot or security state of an instance, so if your instance is compromised you can isolate it easily with a quick security group rule change. This does not mean you don’t still need host firewalls. They still play a valuable role when you need extra granularity, such as protecting instances when they move between different security groups. Another use for a host firewall is to provide the administrator with control over the specific instance’s security without requiring cloud management layer changes. Security group capabilities vary widely between platforms but the basic principles are pretty consistent. They also don’t necessarily substitute (yet) for more advanced firewall/IPS setups, which is when virtual appliances or some of the fancy integrated technologies (such as what VMWare is doing with vShield) come into play to inspect inter-VM traffic. The more I use them the more I am becoming a big fan of security groups, even with their limitations. They are pretty dumb, without even basic stateful packet inspection capabilities. Long term, any network security tools that want to play well with the cloud will need to adopt the same degree of integration with security groups implemented via the cloud platform, as well as access to those controls via robust cloud APIs. Share:

Share:
Read Post
dinosaur-sidebar

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.