Research

A note on project management: One client was quite disappointed with me for not showing progress as I went along and said “Fast iteration is better than delayed perfection,” while another client was mad at me because “you’re trickling again,” – showing progress but not a finished product (a\k\a delayed perfection)… A gentle smack upside the head: ask clients how they prefer to deal with project communications! They know what they want and how they want it, and you’d better RECOGNIZE. Note from Rich: In my consulting days I always tried to feel out the client and put reporting expectations in the proposal. Makes everyone happier. Share:

What do we want? API Access! When do we want it? Now! I’s time to change your entire mindset. We’re talking about API security, but not for traditional APIs. API gateways are a response to the “open API” movement, and create a very different development environment. As we mentioned in our introduction, API gateways are an enabling technology, but likely not the way you think they are. Companies want to expose their services to a wide audience, but rather than design and build consumer offerings in-house they often provide API access to their services to contractors – and in many cases to the general programming community. For companies like Twitter, Facebook, and YouTube (Google), the trend is to allow third-party developers to extend and integrate these platforms to provide novel new user experiences. It’s a win/win: the company gets to leverage innovations from the third-party community, users get better apps, and developers get paid (the average force.com developer makes $392k/year for their work. It can be an almost free way to leverage the best ideas in the development world – you just have to accept the risk of random people groping around your services and data. Leveraging the community for innovation and pro bono development raises some new security problems – how can you control your API while actively making it available outside your company? Not that many years ago, companies wrestled with serving up data to consumers outside the firewall – letting them write code to run on top of proprietary systems is downright scary. To provision developer access, and to control what they can use and how, you need some form of API management framework. API gateways are this framework. From the developer’s perspective they function like a traditional development environment: they bundle a number of features under one umbrella to provide basic tools developers need and make API integration as simple as possible. For the API provider, rich and accessible services encourage developers. The flipside is trying to manage developers who don’t work for your company, and giving up control over endpoints and user experience. Additionally, you need to control access and features through tokens and keys. 80% of your API gateway effort will focus on what developers need to leverage your service, but the most difficult 20% will be managing developers’ experience and exposing services, which requires attention on ease of use and hiding complexity from developers. API gateways are for extending features to developers, so most of our examples are from the development perspective. Our outline follows the path developers will take to use your APIs. We will start from ground zero, as developers register themselves to use your service, considering how you will provision developer access. Per the outline in our introduction we will then move into other areas of development tools, key management, and other critical areas of API security. On our journey we will straddle two realms: buyers and builders. For builders, we will show you examples of features you need to build into your platform. For those of you looking to acquire an API gateway, consider this a mirror image of your critical platform criteria and where you will need services to get your deployment over the finish line. Provisioning As simple as it may seem, provisioning for API gateways is a balancing act. On the one hand companies want simple streamlined access for developers to build functionality. On the other hand they want to ensure this all complies with security policies. How can you ensure security while providing developers with full access? What process will ensure the right mix of policy checkpoints without hampering developers? Therein lies the rub. Let’s look at a developer’s first step: getting access to the development environment. Developer access provisioning Perhaps you have heard that developers can be a tad mercurial? Development is about building and enabling, so security controls which restrict usage or limit functions are seen as an impediment and source of friction. Keeping developers on board with security policy is a challenge, especially when any number of them don’t even work for your company. Development tools are typically selected for ease of use, so streamlining access to tools and simplifying access to API functionality is critical. API gateways proxy communications to applications – they act as traffic cops to direct application requests according to policy. That middle ground is a vital place for security to focus for three reasons: It is a boundary between internal and external, making it an ideal place for policy enforcement. It is a logical place to monitor inbound and outbound access. It is where developers get everything they need to create applications. What do developers need to get started coding? They need to be vetted to the API, which means they need to get credentials. These credentials come as tokens and possibly certificates. API gateways should provide what developers need to find and bind to your API to begin coding. First, developers generally need to register with the gateway to initiate the key issuance process and get credentials to your API. This may require a few minutes for a simple automated process, or much longer for requests which require manual review. Once accepted, developers receive credentials – often only to a development and testing instance, with production access to follow. How this process works, and how simple it is to implement, are important factors for selecting an API gateway. How well can your candidates be tuned to your organizational needs? When building an API gateway, be realistic about what developers will tolerate in terms of delay and complexity. Grand processes with many steps tend to stop developers in their tracks. The API documentation is another major factor in simplifying developers’ lives. The favorite words of many developers are “for example”, typically followed by a code snippet and a usage explanation. The goal is to get developers up and running quickly so look for code samples, reference implementation, and test clients when you evaluate API gateways. A wide variety of languages are in play, so over time you will likely your own miniature

Are you aware of a theft of big data? I will ask in a slightly different way: Do you know of any instance where a commercial big data cluster was exposed to an attacker who mined the cluster for fun or profit? Hackers are unlikely to copy a big data set – why bother moving terabytes when they can use your cluster to store and process your data. I am unaware of any occurrences, public or private. And no, LexisNexis and ChoicePoint, where the attackers had valid user credentials, don’t count. Please comment if you know of an example. I ask because I have been reading about how vendors are combatting the billions of dollars of theft in the big data space, but I am unaware of any such big data cyberthefts. In fact I have not heard of one dollar being stolen. Unless you count the NSA collection of vast amounts of personal data as thieving, but I hope we can agree that is different in several ways. So my question stands: “Who was attacked? Where did the thefts occur?” I don’t want to deprecate security around big data clusters because we have not yet seen an attack – we do need cluster security, and I am certain we will eventually see attacks. But hyperbole won’t help anyone. Executive management teams have heard this FUD before. In the early days before CISO’s, security cried “Vulnerabilities will eat your grandmother!” one too many times, and management turned their collective backs. This round of FUD will not help IT teams get budget or implement security in and around big data clusters. Another question: Are you aware of any security analytics tools, policies, algorithms, or MapReduce queries that can detect a big data breach? I doubt it. Seriously doubt it. The application of big data and data mining for security is focused on fraud detection and bettering SIEM threat detection capabilities. As of this writing no SIEM tool protects big data. No one has written a MapReduce query to find “the bad buys” illegally using a big data cluster. Today that capability does not exist. We have only the most basic monitoring features to detect misuse of big data clusters from the Database Activity Monitoring vendors – they are so limited that they are barely worth mentioning. Of course I expect all this to change. We will see attacks on big data, and we will see more security tools focused on protecting it, and we will use analytics to detect misuse there as well as everywhere else. When that will change, I cannot say. After the first few big data breaches, perhaps? On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s DR post: Why Database Assessment. Adrian’s white paper on What Every DBA Should Know. Favorite Securosis Posts Adrian Lane: Getting to Know Your Adversary. Mike Rothman: Security Analytics with Big Data: Integration. All Adrian needs is to mention either BYOD or APT in this blog series to hit the security marketing hyperbole trifecta! Kidding aside, he is doing a good job structuring the discussion of how to leverage big data to solve security problems. Other Securosis Posts We are all guilty of something. Talking Head Alert: Mike on Phishing Webcast. Incite 6/12/2013: The Wall of Worry. The Securosis Nexus Beta 2 Begins! Network-based Malware Detection 2.0: The Network’s Place in the Malware Lifecycle. Security Analytics with Big Data: Integration. DDoS: It’s FUD-eriffic! Quick thoughts on the iOS and OS X security updates. Groupthink Kills Your Security Layers. A truism of security information sharing. Getting to Know Your Adversary. Friday Summary: June 7, 2013. Favorite Outside Posts Rich: Gartner Reveals Top 10 IT Security Myths. Not sure this is the top 10 but it is a good list. Item 3 lacks nuance, however. Adrian Lane: Upcoming revelations speculations. Robert Graham has been on a roll lately. This ‘revelations’ post is a fun read, throwing scenarios out there and seeing what’s plausible, furthering the Snowden Leaks story line. The Skype speculation is unsettling – it is both entirely plausible and simultaneously sounds totally insane to normal people: two common elements of many declassified cold war stories. Mike Rothman: Sacke Notes: Cofficers – A New Breed in a New Economy. I will probably use this as an Incite topic, but it’s a pretty good view into my working lifestyle. In fact I am in my coffee shop office now putting this link in. How perfect is that? Research Reports and Presentations 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. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts The Secret War. Profile of the man running US ‘cyber-war’ efforts. Microsoft Disrupts Citadel botnet. Facebook Unveils Presto. Speedy replacement for Hive. Cyber Security and the Second Amendment. Banker’s Nap Costs Millions. Lawsuit filed over NSA phone spying program. Microsoft Security Bulletin Summary for June 2013. Democratic Senator Defends Phone Spying, And Says It’s Been Going On For 7 Years. Expert Finds XSS Flaws on Intel, HP, Sony, Fujifilm and Other Websites. Blog Comment of the Week This week’s best comment goes to -ds, in response to A truism of security information sharing. Maybe information sharing will be easier now that we know the NSA have it all already. Share:

Alex Hutton has been on the leading edge of IT security risk management as long as I have known him. He has a new blog, and if you don’t think we can ever quantify risk, you need to read this post The next age of risk management, science, & craftsmanship: And that’s the crux of the third age, the move to what I’ve past referred to as a Modern Approach to Risk Management (borrowing heavily from the white page of the same name). Forward thinking programs are blending things like fraud analytics, InfoSec controls, and risk modeling so that there is no longer a boundary between these disciplines. Even folks who are grumpy sticks in the mud about risk, big data and so forth have had to acknowledge the benefits of at least basic “Data Science” methods. Alex is using some of these techniques in the real world. I have always challenged any quantitative risk modeler to show me a model that consistently and reasonably accurately predicts security outcomes. A few people are close, but not likely using any of the models you have been taught. Alex and some others, including Jack Jones, are taking a scientific approach and slowly making progress. I expect that some day during my career a model will pass my risk management test, thanks to their hard work. That will change our profession dramatically. Share:

Moxie Marlinspike has a must-read editorial over at Wired: For instance, did you know that it is a federal crime to be in possession of a lobster under a certain size? It doesn’t matter if you bought it at a grocery store, if someone else gave it to you, if it’s dead or alive, if you found it after it died of natural causes, or even if you killed it while acting in self defense. You can go to jail because of a lobster. If the federal government had access to every email you’ve ever written and every phone call you’ve ever made, it’s almost certain that they could find something you’ve done which violates a provision in the 27,000 pages of federal statues or 10,000 administrative regulations. You probably do have something to hide, you just don’t know it yet. I’ve mostly stayed away from the recent NSA news because it isn’t infosec per se. But here’s the thing: private businesses are collecting what are essentially our innermost thoughts (search engines, email, writing, what you read online, etc.) – never mind our physical locations and physical actions. If someone in a position of power decides to look at you they will find something. I recently had a friend threatened, very directly, merely for speaking out against something innocuous in a public forum. I support our government and law enforcement, but I also believe in privacy and appropriate checks and balances in the system. The NSA likely hasn’t done anything illegal, but the laws themselves are the issue. These are good people doing the job we put before them, but we neglected to have the serious social discussion about the potential consequences first. I will step down off the soapbox now. Share:

If you have nothing better to do tomorrow at 2 pm EDT, and want to learn a bit about what’s new in phishing (there is a lot of it, but that’s not new) and how to use email-based threat intelligence to deal with it, join me and the folks from Malcovery Security on a webcast tomorrow. I will be covering the content in the Email-based Threat Intelligence paper, and the folks from Malcovery will be sharing a bunch of their research into phishing trends. It should be an interesting event, so don’t miss it… You can register now. Share:

Anxiety is something we all deal with on a daily basis. It is a feature of the human operating system. Maybe it’s that mounting pile of bills, or an upcoming doctor’s appointment, or a visit from your in-laws, or a big deadline at work. It could be anything but the anxiety triggers our fight or flight mechanisms, causes stress, and takes a severe toll over time on our health and well being. Culturally I come from a long line of worriers. Neuroses are just something we get used to, because everyone I know has them (including me) – some are just more vocal about it than others. I think every generation thinks they have it tougher than the previous. But this isn’t a new problem. It’s the same old story, although things do happen faster now and bad news travels instantaneously. I stumbled across a review of a 1934 book called You Can Master Life, which put everything into context. If you recall, 1934 was a pretty stressful time in the US. There was this little thing called the Great Depression, and it screwed some folks up. I recently learned my great-grandfather lost the bank he owned at the time, so I can only imagine the strain he was under. The book presents a worry table, which distinguishes between justified and unjustified worries and then systematically reasons why you don’t need to worry about most things. For instance it seems this fellow worried about 40% of the time about disasters that never happened, and another 30% about past actions that he couldn’t change. Right there, 70% of his worry had no basis in reality. When he was done he had figured out how to eliminate 92% of his unjustified fears. So what’s the secret to defeating anxiety? What, of this man, is the first step in the conquest of anxiety? It is to limit his worrying to the few perils in his fifth group. This simple act will eliminate 92% of his fears. Or, to figure the matter differently, it will leave him free from worry 92% of the time. Of course that assumes you have rational control over what you worry about. And who can really do that? I guess what works best for me is to look at it in terms of control. If I control it then I can and should worry. If I don’t I shouldn’t. Is NSA surveillance (which Adrian and I discuss below) concerning? Yes. Can I really do anything about it – beyond stamping my feet and blasting the echo chamber with all sorts of negativity? Nope. I only control my own efforts and integrity. Worrying about what other folks do, or don’t do, doesn’t help my situation. It just makes me cranky. They say Wall Street climbs a wall of worry, and that’s fine. If you spend your time climbing a similar wall of worry you may achieve things, but it will be at great cost. Not just to you but to those around you. Take it from me – I know all about it. To be clear, this is fine tuning stuff. I would not ever minimize the severity of a medical anxiety disorder. Unfortunately I have some experience with that as well, and folks who cannot control their anxiety need professional help. My point is that for those of us who just seem to find things to worry about, a slightly different attitude and focus on things you can control can do wonders to relieve some of that anxiety and make your day a bit better. –Mike Photo credit: “Stop worrying about pleasing others so much, and do more of what makes you happy.” originally uploaded by Live Life Happy 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. API Gateways Security Enabling Innovation Security Analytics with Big Data Integration New Events and New Approaches Use Cases Introduction Network-based Malware Detection 2.0 The Network’s Place in the Malware Lifecycle Scaling NBMD Evolving NBMD Advanced Attackers Take No Prisoners Quick Wins with Website Protection Services Deployment and Ongoing Management Protecting the Website Are Websites Still the Path of Least Resistance? 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 Snowing the NSA: Once again security (and/or monitoring) is front and center in the media this week. This time it’s the leak that the NSA has been monitoring social media and webmail traffic for years. Perhaps under the auspices of a secret court, and perhaps not. I believe Rob Graham’s assessment that the vast majority of intelligence personnel bend over backward to protect citizen’s rights. But it is still shocking to grasp the depth of our surveillance state. Still, as I mentioned above, I try not to worry about things I can’t control. So how did Edward Snowden pull off the leak? The NY Times has a great article about the gyrations required by reporters over a 6-month period to get the story. A Rubik’s Cube? Really? Snowden came clean, but they would have found him eventually – we always leave a trail. Another interesting link regarding the situation is how someone social engineered the hotel where Snowden was staying to get his room number and determine that he already checked out. If you want to be anonymous, probably beter not to use your real name, eh? – MR Present Tense: As someone who has been blogging on privacy for almost a decade, I am surprised by how vigorous public reaction has been to spying on US citizens via telecom carriers. When Congress and the senate granted immunity to telecoms for spying on users back in 2008, was it not obvious that Corporate entities are now the third party data harvester, and government

We realize it has been a while, but we are insanely excited to open up the next phase of the Securosis Nexus beta test. This is an open beta but we reserve the right to kick out anyone who annoys us. Getting Started Signing into the Nexus is easy. Just go to http://nexus.securosis.com, click “Sign Up” and enter “4111-1111-1111-1111” as your credit card number – sorry if that’s your real credit card number. You will then receive activation information via email.   What to Expect The Nexus is code complete but our content is far from complete. The system is completely functional, so now we need help making sure it scales beyond our internal testing. We have some starter content in there, but it is only representative of where we are headed, and this structure is temporary. We will be adding content weekly basis as we get closer to launch, and will send out occasional updates to beta testers so you know what we are up to. We are fully supporting the “Ask an Analyst” feature, which means you get free advice (well, in exchange for your help testing). But this is a (free) beta test, so we make no promises of timeliness. 🙂 We anticipate staying in test mode for 3-6 months because it will take at least that long to write all the content. Most of the material is brand new, and this isn’t merely a repository for our white papers. If you find bugs or have questions, email us at nexus@securosis.com or use the Support link. Thanks! We are really looking forward to getting more people into the system and taking it for a test drive. Share:

Some of our first customer conversations about big data and SIEM centered on how to integrate the two platforms. Several customers wanted to know how they could pull data from different existing log management and analytics systems into a big data platform. Most were told by their vendors that big data was; and they wanted to know what that integration would look like and how it would affect operations. Likely you won’t be doing the integration, but you will need to live with the design choices of your vendor. The benefit depends on their implementation choices. There are three basic models for integration of big data with SIEM: Log Management Container Some vendors have chosen to integrate big data while keeping their basic architecture: semi-relational or flat file system which supports SIEM functions, and fronts a big data cluster which handles log management tasks. We say ‘semi-relational’ because it is typically a relational platform such as Oracle or SQL Server, but stripped of many relational constructs to improve data insertion rates. SIEM’s event processing and near real-time alerts remains unchanged: event streams are processed as they arrive, and a specific subset of events and profile information stored within a relational – or proprietary flat file – database. Data stored within the big data cluster may be correlated, but normalization and enrichment is only performed at the SIEM layer. Raw events are streamed to the big data cluster for long-term storage, possibly compressed. SIEM functions may be supported by queries to reference specific data points within the big data archive but support is limited. In essence big data is used to scale event storage and accommodate events – regardless of type or format. Peer-to-Peer Like the example above, in this scenario real-time analysis is performed on the incoming event stream, and basic analysis performed in a semi-relational or flat file database. The difference here is functional rather than architectural. The two databases are truly peers – each provides half the analysis capability. The big data cluster periodically re-calculates behavioral profiles and risk scores, and shares these with SIEM’s real-time analysis component. It also processes complex activity chains and multiple events tied to specific locations, users or applications may that indicate malicious behavior. The big data cluster does a lot of heavy lifting to mine events, and shares these updated profiles with SIEM to hone policy enforcement. The big data cluster allows provides a direct view for Security Operations Centers (SOC) to run ad hoc queries on a complete set of events to look for outliers and anomalous activity. Full Integration The next option is to leverage only big data for event analysis and long term log storage. Today most of these SIEM platforms use proprietary file systems – not relational databases or big data. These proprietary systems were born of the same need to scale to accommodate more data with less insertion overhead than big data. These proprietary repositories were designed to provide clustered data management, distributing queries across multiple machines. But they are not big data – they don’t have the essential characteristics we defined earlier, and often don’t have the the 3Vs either. You will notice that both peer-to-peer and log management oriented versions use two databases; one relational and one big data. There is really no good reason to maintain a relational database alongside a big data cluster – other than the time it takes to migrate and test the migration. That aside, it is a simple engineering effort to swap out a relational platform with a big data cluster. Big data clusters can be assembled to perform ultra fast queries, or efficient large scale analysis, or leverage both types of queries on a single data set. Many relational features are irrelevant to security analytics, so they are either stripped out for performance or remain present, reducing performance. Again, there is no reason relational databases must be part of SIEM – the only impediment is the need to re-engineer the platform to swap the new cluster in. This does not exist today but expect it in the months to come. Continuing this line of thought, it is very interesting to think of ways to further optimize a SIEM system. You can run more than one big data cluster, each focused on a specific type of operation. So one cluster would run fully indexed SQL queries for fast retrieval while another might run MapReduce queries to find statistical outliers. In terms of implementation, you might choose Cassandra for its index capabilities and native compression, and Hadoop for MapReduce and large-scale storage. The graphic to the right shows this possibility. It is also possible to have one data cluster with multiple query engines running against the same data set. The choice is up to your SIEM vendor, but the low cost of data storage and processing capacity mean the performance boost even from redundant data stores is still likely to outweigh the costs of added processing. The fit for security analytics is largely conjecture, but we have seen both models scale well for various other data analyses. Standalone Those of you keeping score at home have noticed I am throwing in a fourth option: the standalone or non-integration model. Some of our readers are not actually interested in SIEM at all – they just want to collect security events and run their own reports and analysis without SIEM. It is perfectly feasible to build a standalone big data cluster for security and event analytics. Choose a platform optimized for your queries (fast, or efficient, or both if it is worth building multiple optimized clusters), the types of data to mine, and developer comfort. But understand that you will need to build a lot yourself. A wide variety of excellent tools and logging utilities are available as open source or shareware, but you will responsibility for design, organization, and writing your own analytics. Starting from scratch is not necessarily bad but all development (tools, queries, reports, etc.) will fall to your team. Should you choose to integrate with SIEM or log management, you will

FUD can be your friend when trying to get security projects funded. But it needs to be wisely used and you only have one bullet in the proverbial chamber. The folks at Prolexic just rolled out a new white paper on using FUD to make the case internally about DDoS. The paper requires registration, so I didn’t. I know all about the FUD involved in DDoS – I don’t need these guys educating me about that. So here are some really FUD-elicious reasons why business folks need to be worried about DDoS: The damage from a DDoS attack actually goes far beyond IT and can impact: Stock price and investor confidence Sales revenues and profitability Brand reputation Customer service Employee morale Search engine rankings and more How’s that for some chicken little action? I think a DDoS may clog your toilets as well, so bring the plungers. And make sure you have psychologists on call – employee morale will be in the dumpers with every incremental 10Gbps of DDoS traffic hammering your systems. And your scrubbing center can make it all better. Just ask them. Yes, I’m being a bit facetious. OK, very facetious. I can imagine investors have no faith in the Fortune 10 banks that get hammered by DDoS every day. Man, I could go on all day… Anyhow, this one was just too juicy to let pass. Now I’ll get back to doing something productive… Share: