Securosis

Research

Friday Summary: Favorite Films of 2014 (Redux)

Rich here. Something went wonky so most of the Summary didn’t load properly on Friday. So I am reposting with the lost content… The Securosis blog has been around since 2006, with pretty much constant posts over that entire time (multiple posts a week, with a few exceptions). That is a lot of words, a large percentage of which came through my keyboard. We have always used the Summary (and when Mike joined, the Incite) to add some color to our security coverage, and give glimpses into our personal lives, or random thoughts that don’t really fit in a security-oriented blog post. I will expand on that in some posts this year, starting today with a post on my favorite films of 2014. Yep, you heard me, and you can skip to the Summary itself below if you just want the top links and news of the week. Favorite Films of 2014 These aren’t necessarily the best movies of the year – not even close – but the ones I most enjoyed. My wife and I are huge film buffs, but since having (3 young) kids we dropped from seeing movies near weekly, to monthly if we are lucky. This changed our tastes because due to constant exhaustion we are more likely to pick something light and fun than arty and independent (we still watch those, usually over 2 nights, at home). Top Films I Saw in a Theater Guardians of the Galaxy: Flat out, the most fun I had in a theater all year. I saw it twice, then bought the Blu-Ray (3D with digital copy) for home. Some consider comic book films the death of ‘serious’ movies, but as we transition deeper into the digital age spectacles like this will sustain movie theaters and allow more serious films to still show in the smaller rooms at the back of the megaplex. Captain America: The Winter Soldier: Almost my #1 pick because this one elevated the ‘classic’ comic-book genre film. Its comments on society were heavy-handed but the timing was perfect – especially if you know what’s coming in the Civil War storyline. But what really hooked me were the effects and character of Cap himself. His movements, style, and pure kinesis made even the Avengers action scenes look pedestrian. Gravity: I love space. I went to Space Camp three times as a kid (and considering our limited household income, that was more than a big deal). The science may have been way off in parts, but the immersive 3D IMAX experience was incredible. And the tension? Oh, the tension! It makes me almost want to cry that I missed seeing Interstellar on an IMAX screen. Favorite Film Most of You Skipped Edge of Tomorrow: This did poorly in the theaters, and we only watched it on an iPad at 35,000 feet ourselves, but I immediately bought the book on my Kindle when we landed. If you have ever ground out a level in a video game this is the movie for you. If you want to see Tom Cruise die, a lot, this is the movie for you. If you want to see the best time-travel film since Looper… you know the rest. And definitely read the book. The One We Loved Until Our iTunes Rental Expired The Grand Budapest Hotel: I have the Blu-Ray from Netflix sitting here so we can watch the last 20 minutes. But unless they completely suck this was Wes Anderson at his best. Amazing style, characters with panache, and his usual visual splendor. The One I Enjoyed, but Really Didn’t Get As Much As Anyone Else Snowpiercer: I get it, Bong Joon-Ho is awesome and Tilda Swinton just nailed it, but I still don’t understand why this made so many Top 10 lists. It was good, but not that good. My Favorites with the Kids Our girls are finally old enough to sit through and enjoy a movie with, and this was an awesome year to bond in a theater (or with a rental). The Lego Movie: I really really really wish we had seb this in the theater, instead of on video, but we all loved it. Our dining room table has been covered in Legos for months, and I don’t expect that to change anytime soon. The message hit the perfect tone of “be creative, but sometimes you still need to listen to your damn parents so you don’t die a tragic death!” Maybe I’m projecting, a little. How to Train Your Dragon 2: Oh, wow. Even on a smaller 3D TV at home this is still amazing (we did see it in a theater first). It goes where few kids films have the balls for any more, putting you on an emotional roller coaster with plenty of spectacle. I really love this series, and will be sad when it ends with the next one. Big Hero 6: Another one full of emotion, evoking classic Disney themes in a fully modern, comic-book tale. It could have gone horribly wrong and is far from perfect, but the kids loved it, we enjoyed it, and the visual design is truly special. I wouldn’t place this up there with The Incredibles, but it really shines is creating bonds between the audience and the main characters. Favorite Comedy Neighbors: I enjoyed 22 Jump Street, but Neighbors had a few scenes that floored me. Let’s be honest – I am at a stage of life where I can appreciate a hangover + full boobs joke more than when I was 20 or 30. The One I Will Only See in Private Boyhood: I have kids. I’m going to cry. Screw you if you think I’m doing that in a theater. The Best Movie to See While Hopped up on Painkillers after… Guy Surgery G.I. Joe: Retaliation: Not much else to say. I dare you to refute. There are a lot of other films I enjoyed, especially Dawn of the Planet of the Apes, but these

Share:
Read Post

Incite 1/7/2014: Savoring the Moment

Early December is a big deal in our house. It’s Nutcracker time, with both girls working all fall to get ready for their dance company’s annual production of the Xmas classic. They do 5 performances over a weekend, and neither girl wants it to end. We have to manage the letdown once that weekend is over. It has been really awesome to see all of the dancers grow up, via the Nutcracker. They start as little munchies playing party boys and girls in the first scene, and those who stick with it become Dew Drop or possibly even the Sugarplum Fairy. The big part for XX1’s group this year was Party Clara. It’s on Pointe and it’s a big and featured role in Act 1. She has been dreaming about this part for the past 4 years, and when we heard she got it for one of the performances this year, we knew it was going to be a special Nutcracker. She also got a featured Rag Doll part for another performance and was on stage 4-5 times during the show. XX2 wasn’t left out, and she got a number of featured parts as well. I used to dread that weekend but the girls didn’t really do much, so I could get away with going to one performance and being done with it. Now I attend 3 out of the 5 performances, and would go to all 5 if the girls had sufficient parts. I’m pretty sure the Boy wouldn’t be happy going to 5 performances, but he’ll get over it. I even skipped a home Falcons game to see the Sunday afternoon performance (I did!). One of the things I am working on is to pause during the big stuff and just enjoy it. You could call it smelling the flowers or something like that. For me it’s about savoring the moment. To see XX1 with a grin ear to ear performing as Party Clara was overwhelming for me. She was so poised, so in command, so happy. It was incredible. During those 3-4 minutes the world fell away. There was only my girl on stage. That’s it. Some folks watch their kids perform through a camera viewfinder. Or a cellphone screen while taking video. Not me. I want to experience it directly through my own eyes. To immerse myself in the show. I want to imprint it in my memory. Yes, we’ll buy the DVD of the performance, but that’s for the folks who weren’t there. I don’t need it. I was fully in that moment, and I can go back any time I want. And I do. –Mike Photo credit: “P1-VS-P2” originally uploaded by MoreInterpretations The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon 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, with our content in all its unabridged glory. And you can get all our research papers too. Security Best Practices for Amazon Web Services Third Party Tools Built-in Features Introduction Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Migration Planning Technical Considerations Solution Architectures Emerging SOC Use Cases Introduction Security and Privacy on the Encrypted Network Selection Criteria and Deployment Use Cases The Future is Encrypted Newly Published Papers Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection The Future of Security Incite 4 U Security deadly sin: offensive envy: I dug up Richard Bejtlich’s awesome post from right before New Year, where he dismantles a list from Microsoft’s John Lambert and calls him out for minimizing the potential of defensive security. It is true that hacking stuff is sexy, and the chicks & dudes dig it. But still, the fact that many defenders work off checklists doesn’t mean all do. Because the defenders seem to come up on the losing end of some breach every day doesn’t mean their efforts are pointless. It means it’s a hard job, pure and simple. And glorifying the adversary only provides a defeatist attitude before you even start playing. Which I guess is the adversary’s plan… – MR No hands: I just love it when someone comes up with an entire class of security vulnerability – and if it might affect an Apple product guess what’s in the headlines? Like the general GSM wireless issue that was hyped as “iPhones Vulnerable” (every GSM phone was vulnerable). That hype sometimes does the issue a disservice, as highlighted in this piece at the Huffington Post on Jan Krissler recreating thumbprints from normal photographs at the Chaos Computer Club. It’s a fascinating and brilliant idea as we progress towards ubiquitous high-definition cameras throughout the world. Not merely for hacking phones, but for all the CSI-spinoff episodes it will inspire. Practically speaking,

Share:
Read Post

Summary: That’s a Wrap!

Rich here, Holy crap, what a year! I have been in the security business for a while now. I wouldn’t say I am necessarily jaded, but… yeah. Wow. First, the news. This was the year of Target and Sony. Symantec finally breaking up. All sorts of wacky M&A. The year family members checked in for the first time in decades, after reading my quotes in articles with “celebrity nudes” in the headlines. Apple getting into payments. My guidance counselor totally left that out when we discussed infosec as a career option. Not that infosec was a career option in the late 80’s, but I digress. As I have often said, life doesn’t demarcate itself cleanly into 365 day cycles. There is no “year of X” because time is a continuum, and events have tendrils which extend long before and after any arbitrary block of time. That said, we will sure as hell remember 2014 as a year of breaches. Just like 2007/2008, for those who remember those ancient days. It was also a most excellent year for general security nonsense. Then there was the business side. 2014 was an epic year for Securosis on every possible level. And thanks to the IRS and our fiscal year being the calendar year, we really do get to attribute it to 2014. We cranked out a bunch of papers (mostly Mike) and engaged in some insanely fun projects (mostly me). A year or so ago I wasn’t sure there was enough of a market for me to focus so much of my research on cloud and DevOps. Now I wonder if there’s enough of me to support all the work. We were so busy we didn’t even get around to announcing a new research product: Securosis Project Accelerators. Focused workshops for end users and (for now) SaaS providers tied to specific project initiatives (like our Cloud Security for SaaS Providers package). On the upside, we sold a bunch of them anyway. The main thing that suffered was this blog. We mostly kept up with our scheduled posts and open research, but did drop a lot of the random posts and commentary because we were all so busy. I wish I could say that’s going to change, but the truth is 2015 looks to be even busier. Personally this has been my favorite work year yet, due to the amount of primary research I have been able to focus on (including getting back to programming), working more with end-user organizations on projects, and even getting to advise some brand-name cloud providers on technical aspects of their security. I am not sure whether I mentioned it on the site, but my wife stopped working after RSA due to an acute onset of “too many children”. We decided it was no longer worthwhile for both of us to work full time. And changes in the healthcare system meant we were no longer so reliant on her employee benefits. That reduced a lot of home scheduling stress, but also meant I was short on excuses to stay off airplanes. I was definitely away from home a lot more than I liked, but when I am home, I get to be far more engaged than a lot of parents. On the non-work front it was also an awesome year. We are done with babies (but not diapers), which means we are slowly clawing back some semblance of a life outside being parents. Our older two started in public school, which is like some kind of fantasy after years of paying a prison company to keep our children mostly alive and intact (daycare… shudder). We spent a month in Boulder, a week in Amsterdam, and a weekend in Legoland. I am running as fast as I was in my 20’s, over longer distances, and I am almost not embarrassed on the bike. (Remember, triathlon is latin for “sucks at three sports”). So on the overall good/bad scale I would mark 2014 as “awesome”. Mostly because I don’t work for a retailer or a film studio. And, without going into details, 2015 has some serious potential for epic. As I like to do every year before we close down for the holidays, I would really like to thank all of you for supporting us. Seriously, we are 3 guys and a half-dozen friends with a blog, some papers, and a propensity to sit in front of webcams with our clothes on. Not that many people get to make a living like this, and we can only pull it off due to the tremendous support you have all given us for over 7 years. I may not be religious but I sure am thankful. On to the Summary (our last this year): Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in the Guardian on the Sony breach Favorite Securosis Posts Mike Rothman: Firestarter: Predicting the Past. I can only hope you had half as much fun watching as we had recording the year-end FS. That’s right vendors – think twice before making those predictions. Even if you’re our friends, we will still call you out! Rich: Ditto. Natch. Other Securosis Posts Security Best Practices for Amazon Web Services: Third Party Tools. Security Best Practices for Amazon Web Services: Built-In Features. Security and Privacy on the Encrypted Network: Selection Criteria and Deployment. Firestarter: Predicting the Past. Summary: Nantucket. Favorite Outside Posts Adrian Lane: Analyzing Ponemon Cost of Data Breach. Jay Jacobs does an excellent job analyzing Ponemon’s breach cost calculation model. And I even learned a new word: heteroskedasticity. Mike Rothman: Analyzing Ponemon Cost of Data Breach. Don’t screw with Jay Jacobs on data stuff. Just don’t do it. This is a gem: “And in this analysis I will not only show that the approach used by Ponemon is not just overly simple, but also misleading and even may be harmful to organizations using the Ponemon research in their risk analyses.” Damn. Jay wins. Rich: I suppose I should choose something else.

Share:
Read Post

Security and Privacy on the Encrypted Network: Selection Criteria and Deployment

Our Use Cases post ran through setting policies for decryption, and specific use cases driving decryption of network traffic. We also brought up human resources and compliance considerations when building policies. But that doesn’t address the technical nuances of actually figuring out where to decrypt, or how to select and deploy the technology, so here we go. First let’s talk a bit about whether you need a standalone device. Standalone or Integrated? Many network and security devices can terminate and decrypt network sessions – including firewalls, IPS, load balancers, UTM, and web & email security gateways. Obviously using an existing device is simpler, often the path of least resistance for decryption and inspection. You don’t have to add other boxes or risk messing up your network addressing scheme, and you can enforce policies right at the point of decryption/inspection. A security device can decrypt traffic, inspect it, apply policy, and re-encrypt – all within a single product. For environments with minimal network volumes and simple policies, integrated devices work well. But those who need to decrypt substantial network traffic tend to quickly crush the performance of existing security devices if they try to decrypt on existing devices. As we mentioned in our last post, onboard decryption may reduce performance of security devices by 33% to 80%. If you have plenty of performance headroom on your security devices that’s OK. If you don’t you need to look at another device to offload decryption load, in order to let your security devices do what they do best: inspect traffic, apply policies, and monitor or capture traffic. If you deploy complicated policies, such as multiple policy triggers across the entire network stream rather than limiting yourself to port 443 (HTTPS), an integrated device’s relatively simple decryption policies may be insufficient. Additionally, if you need to send decrypted traffic to multiple places, such as a SIEM or network packet capture device, an integrated solution may not be a good fit. We have nothing against the integrated option, but pragmatism and drives us toward the right tool for the job. If onboard decryption can meet your performance and policy requirements, do it. But if not you likely need a standalone decryption device. Selection Criteria Once you have decided to use a dedicated decryption device, what should you look for? Here are a few things to think about: Performance: Much of the value of dedicated hardware is its ability scale up with traffic volume. Make sure any device or devices you buy can scale to your current and future volumes. Don’t paint yourself into a corner by buying equipment that will need to be replaced when traffic volume grows. All Port Support: One of the easiest evasion techniques for attackers is to simply change the port number of their outbound traffic, sending encrypted traffic where it is not expected or monitored. Inspection devices cannot afford to trust port numbers – you need deep packet inspection looking at payloads to detect evasion. Accuracy: Decryption strategy is highly policy dependent, so success requires accurate categorization of traffic. Related to looking at the full traffic stream, you need to ensure your devices accurately find encrypted traffic and categorize it effectively. Policy actions: Once you have a policy hit, make sure your device supports a variety of different actions. You should be able to decrypt, not decrypt, drop the session, or reject the session (with a website failure code). You also want the ability to list sources or destinations as always decrypt (blacklist) or never decrypt (whitelist), by group or user. Website category/reputation support: A big chunk of our use case post talked about setting policies; they may include websites, IP addresses, and applications. Given how quickly website reputation and categories change (minutes – if not seconds), it is important to have a dynamic source of current information to base policies on. That usually means some kind of cloud-based website categorization service for whitelisting, along with dynamic reputation scoring for websites and applications. Multiple device support: Given the varied decryption use cases, these devices should be flexible in how they forward traffic, and to how many devices. For example you might want to send traffic to both an IPS for active control, and also a packet capture device for monitoring and forensics. It is also important for decryption devices to interoperates natively with security devices, so that (for instance) an IPS which detects decrypted attack traffic can drop that session without human intervention. Security: This is a security device, so you will want to ensure that decryption/resigning keys and data on the device are protected. You also want the ability to reject/drop sessions if their security is insufficient. For example a weak encryption cipher could data at risk; it might be forbidden to transmit encrypted data which cannot be decrypted by the security device, to prevent unknown data from leaving your environment. Transparency: It is also important to ensure decryption doesn’t impact application behavior or user interaction. End users should not need to concern themselves with security inspection. Further, the decryption device shouldn’t alter packet headers in any way, as that might impair other security devices’ inspection. Basically, nobody should know the device is there. Deployment flexibility: Decryption needs to be inserted into the flow of traffic, so you want a device that supports multiple deployment models, discussed below. For devices with multiple ports, you should have flexibility in assigning them to specific devices. You should also be able to apply policies both actively and passively. Deployment Decryption device deployment should be as non-disruptive as possible. You don’t want to mess around with IP addressing schemes, force every user to see a security warning every time they make an SSL connection, or have the device manipulate IP address headers and screw up your ability to monitor and analyze traffic. You want transparency, as mentioned above. Also make sure you are seeing all relevant traffic. Don’t make assumptions about what is relevant and what isn’t. Attackers frequently hide encrypted traffic on

Share:
Read Post

Security Best Practices for Amazon Web Services: Third Party Tools

This is our third post on AWS security best practices, to be compiled into a short paper. See also our first post, on defending the management plane and our second post, on using built-in AWS tools. Finish with Additional Security Tools AWS provides an excellent security foundation but most deployments require a common set of additional tools: Amazon’s monitoring tools (CloudTrail, CloudWatch, and Config) offer incomplete coverage, and no correlation or analysis. Integrate their feeds into existing log management, SIEM, monitoring, and alerting tools that natively support and correlate AWS logs and feeds, so they can fill gaps by tracking activity AWS currently misses. Use a host configuration management tool designed to work in the cloud to automatically configure and update instances. Embed agents into approved AMIs or bootstrap through installation scripts. Insert baseline security policies so all instances meet security configuration requirements. This is also a good way to insert security agents. Enhance host security in key areas using tools and packages designed to work in highly dynamic cloud deployments: Agents should be lightweight, communicate with the AWS metadata service for important information, and configure themselves on installation. Host Integrity Monitoring can detect unauthorized changes to instances. Logging and alerting collect local audit activity and alerts on policy violations. Host firewalls fill gaps left by security group limitations, such as rule set sizes. Some tools can additionally secure administrator access to hosts without relying solely on ssh keys. For web applications use a cloud-based Web Application Firewall. Some services also provide DDoS protection. Although AWS can support high levels of traffic, DDoS protection stops traffic before it hits your instances… and your AWS bill. Choose security assessments and scanning tools that tie into AWS APIs and comply with Amazon’s scanning requirements. Look for tools that not only scan instances, but can assess the AWS environment. Where to Go from Here These fundamentals are just the surface of what is possible with cloud security. Explore advanced techniques like Software Defined Security, DevOps integration, and secure cloud architectures. Share:

Share:
Read Post

Firestarter: Predicting the Past

In our last Firestarter for this year, Mike, Adrian, and I take on some of the latest security predictions for 2015. Needless to say, we aren’t impressed. We do, however, close out with some trends we are seeing which are likely to play out next year, and are MOST DEFINITELY NOT PREDICTIONS. One warning: despite a lack of Guinness, we use some bad words, so let’s just brand this NSFW. Unless your workplace is like ours – then go for it. Lastly, here are links to the predictions we called out (the only ones we found – feel free to mention more in the comments): Websense. Which we didn’t read because you need to register to see them. Trend Micro. Home of the legal disclaimer in case you get hacked after believing their predictions. Kaspersky. A hard one to rip because we have friends there. Netwrix. Yeah, we don’t know who they are either. Vormetric. Another company we like, but we haz to play fair. My 2011 security predictions. I keep renewing them every year, without change. Still mostly holding up – I estimate I hit 70-80% accuracy for 2014. The audio-only version is up too. Share:

Share:
Read Post

Security Best Practices for Amazon Web Services: Built-In Features

This is our second post on AWS security best practices, to be compiled into a short paper. The first post on defending the management plane is here. Implement Built-in AWS Infrastructure Security Features Once you lock down and establish monitoring for your Amazon Web Services management plane, it’s time to move on to protecting the virtual infrastructure. Start with these tools that Amazon provides: Use Security Groups and VPCs for network defense AWS uses a proprietary Software Defined Network with more security than physical networks. All new accounts on AWS use Virtual Private Clouds for underlying networking, giving you extensive control over network configurations, allowing you to run dozens or hundreds of separate virtual networks. Security Groups combine features of network and host firewalls. They apply to groups of instances like a network firewall, but protect instances from each other like a host firewall. These are the basis of AWS network security: By default, instances in the same security group can’t talk to each other. This prevents attackers from spreading horizontally. Separate application components across security groups, with only required ports open between them. External administrative access (ssh or RDP) should be restricted to the IP addresses and subnets used by your administrators. Minimize the number of public subnets, and use NAT gateways to connect private subnets to the Internet as needed, just like most enterprise networks. Establish Access Control Lists to isolate subnets. They aren’t a substitute for security groups, but a complementary tool. Require administrators to connect through a VPN or ssh “jump box” before connecting to instances. This can be an existing Privileged User Management tool. Defend hosts and data AWS is a mixture of Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Amazon bears most responsibility for keeping back-end components secure, but you are still responsible for properly configuring each service and your own instances. IAM is, again, your main tool for defense, but Amazon also offers features which can help you secure instances and protect data. Establish an incident response process for compromised instances and other AWS services. Use the AWS API or command line to collect all metadata, snapshot storage volumes, quarantine with IAM, and quarantine network connections. Design applications to use Autoscaling Groups. Instead of patching running or compromised servers, you can terminate them and replace them with clean up-to-date copies without downtime. AWS supports encryption for several data storage tools – including S3, EBS, and RedShift. You can manage the keys yourself with their Key Management Service (located in the IAM console). Amazon can access keys in the Key Management Service. If you need extra security consider using CloudHSM instead, although service integration isn’t as simple. If you use CloudHSM make sure you have at least two redundant instances so you don’t lose your keys. Amazon cannot view or recover them. Share:

Share:
Read Post

Security and Privacy on the Encrypted Network: Use Cases

In the first post of this series on Security and Privacy on the Encrypted Network, we argued that organizations need to encrypt more traffic. Unfortunately the inability to see and inspect encrypted traffic impairs the ability to enforce security controls/policies and meet compliance mandates. So let’s dig into how to strategically decrypt traffic in order to address a few key use cases – including enforcing security policies and monitoring for security and compliance. We also need to factor in the HR and privacy issues associated with decrypting traffic – you don’t want to end up on the wrong side of a worker council protesting your network security approach. What to Decrypt The first step in gaining visibility into the encrypted network is to set policies for when traffic will be decrypted and for how long. These decisions depend more on organizational culture than anything else, so you need to figure out what will work for your company. As security guys we favor more decryption than less, because that enables more comprehensive inspection… and therefore stronger monitoring and enforcement. But this is a company-specific choice. Several factors influence decryption policies, most obviously the applications themselves. Let’s briefly cover the main applications you are most likely to decrypt: Webmail: Employees think they are doing your organization a favor by working at all times of the day. But this always-on workforce requires use of personal devices, and may decide (however misguided) that it’s easiest to send work documents to personal machines via personal email accounts. What could go wrong? And of course there are more malicious uses for webmail in a corporate environment. There are endpoint DLP agents that should catch this behavior, but if you don’t have them deployed you should be inspecting outbound webmail traffic. The complication is that most webmail is now encrypted so you need to decrypt sessions to inspect the traffic. Web browsing: Similarly social media sites and other web properties utilize user-generated content that may be protected or sensitive, so you need to ensure you can enforce policies on web application traffic as well. Many apps use SSL/TLS by default, so you will need to decrypt to enforce acceptable use policies and protect data. SaaS Apps: Business functions are increasingly migrating to Software as a Service (SaaS) so it is important to inspect SaaS traffic. You may want to enforce tighter content policies on SaaS apps, but first you need to decrypt their traffic for inspection and enforcement. Custom Apps: Similarly your custom web apps (or partner web apps) require scrutiny given the likelihood that they will use sensitive data. As with SaaS apps, you will want to enforce granular policies for these apps, which requires decryption. To net it out, if an application has access to protected or critical data you should decrypt and inspect its traffic. Within each application defined above, secondary attributes may demand or preclude decryption. For example certain web apps/sites should be whitelisted because they handle private employee data, such as consumer healthcare and financial sites. Another policy trigger will be individual employees and groups. Maybe you don’t want to decrypt traffic from the legal team, because it is likely protected and sensitive. And of course there are the folks who require exceptions. Like the CEO, who gets to do whatever he/she wants and may approve an exception for their own traffic. There will be other exceptions (we guarantee it), so make sure your policies include the ability to selectively decrypt and enforce policies. For example one app may need to always be inspected (regardless of user) based on the sensitivity of data it can access. Likewise perhaps one set of users won’t have their traffic inspected at all. You should have flexibility to decrypt traffic to enforce policies, based on applications and users/groups, to accurately map to business processes and requirements. Regardless of the use case for decryption, you will want to be flexible about what gets decrypted, for whom, and when. Where to Decrypt? Now that you know what to decrypt you need to determine the best place to do it. This decision hinges on type of traffic (ingress vs. egress), which applications need to be inspected, and which devices you need to send data to for monitoring and/or enforcement. Firewall: Firewalls frequently take on the decryption role because they is inline for both egress and ingress, and already enforcing policies – especially as they evolve toward application-aware Next Generation Firewalls (NGFW). Unfortunately decryption is computationally demanding, which creates scaling issues even for larger and more powerful firewalls. IPS: IPS is an inspection technology, so an inability to inspect encrypted traffic is a serious limitation. To address this some organizations decrypt on their IPS devices. The IPS function is computationally demanding so these devices tend to have more horsepower, which helps when doing decryption. But as with firewalls, scalability can be an issue. Web filter: Due to their role, web filters need to decrypt traffic. They tend to be a bit underpowered compared to other devices in the DMZ, so unless there is minimal encrypted traffic, they can run out of gas quickly. Dedicated SSL decryption device: For organizations with a lot of encrypted traffic (which is becoming more common), a few dedicated decryption devices are available which specialize in decrypting traffic without disrupting employees, offering flexibility in how to route decrypted traffic for either active controls (FW, IPS, web filter, etc.) or monitoring, and then re-encrypting as it continues out to the Internet. We will get into specifics of selecting and deploying these devices in our next post. Cloud-based offerings: As Security as a Service (SECaaS) offerings mature, organizations have the option to decrypt in the cloud, removing their responsibility for scalability. On the other hand this requires potentially sensitive data to be decrypted and inspected in the cloud, which may be a cultural or regulatory challenge. These devices are typically deployed inside your network permiter, so you remain blind to attackers encrypting internal reconnaissance traffic, or traffic moving

Share:
Read Post

Summary: Nantucket

Rich here. There once was a boy from Securosis. Who had an enormous… to do list. With papers to write… And much coding in sight… It’s time to bag out and just post this. Okay, not my best work, but the day got away from me after spending all week out in the DC area teaching cloud security for Black Hat. Thanks to a plane change I didn’t have WiFi on the way home, and lost an unexpected day of work. Next week will likely be our last Firestarter, Summary, and Incite for the year. We will still have some posts after that, then kick back into high gear come January. 2014 was our most insane year yet, with some of the best work of our careers (okay, mine, but I think Mike and Adrian are also pretty pleased.) 2015 is already looking to give ‘14 a run for the money. And when you run your own small business, “run for the money” is a most excellent problem to have. Unless it involves cops. That gets awkward. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Another quiet week. We promise to return to our media whoring soon. Favorite Securosis Posts Mike Rothman: Summary: 88 Seconds. Rich + tears. I’d need to see that to believe it. But I get it. Very emotional to share such huge parts of your own childhood with your children. Rich: 3 Envelopes. Other Securosis Posts Security and Privacy on the Encrypted Network: Use Cases. Incite 12/10/2014: Troll off the old block. Monitoring the Hybrid Cloud: Migration Planning. Favorite Outside Posts Mike Rothman: Sagan’s Baloney Detection Kit. As an analyst, I make a living deciphering other folks’ baloney. Carl Sagan wrote a lot about balancing skepticism with openness, and this post on brainpickings.org is a great summary. Though I will say sometimes I choose to believe in stuff that can’t be proven. So your baloney may be my belief system, and we shouldn’t judge either way. Rich: Analyzing Ponemon Cost of Data Breach. Jay Jacobs is a true data analyst. The kind of person who deeply understands numbers and models. He basically rips the Ponemon cost of a breach number to shreds. Ponemon can do good work, but that number has always been clearly flawed, and Jay clearly illustrates why. Using numbers. Research Reports and Presentations Securing Enterprise Applications. Secure Agile Development. Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Top News and Posts Due to all the lost time this week I’m a bit low on stories, but here are some of the bigger ones. Iran hacked the Sands Hotel earlier this year, causing over $40 million in damage. Tripwire acquired by Belden. Didn’t see that one coming. $710M. Adobe Patches Flash Player Vulnerability Under Attack. Treasury Dept: Tor a Big Source of Bank Fraud. No surprise, and that’s one Tor vector that should be blocked. Blog Comment of the Week This week’s best comment goes to Ke, in response to My $500 Cloud Security Screwup. This is happening to me… Somehow the credential file was committed in git, which is strange because it is in the .gitignore file. I saw the email from AWS and deleted the key in 30 minutes and I found my account restricted at that time. One day after, however, I found a $1k bill in my account. It is also odd that I did not receive the alert email even though I enabled an alert. I am a student and I cannot afford this money 🙁 Share:

Share:
Read Post

Incite 12/10/2014: Troll off the old block

Every so often the kids do something that makes me smile. Evidently the Boss and I are doing something right and they are learning from our examples. I am constantly amused by the huge personality XX2 has, especially when performing. She’s the drama queen, but in a good way… most of the time. The Boy is all-in on football and pretty much all sports – which of course makes me ecstatic. He is constantly asking me questions about players I’ve never heard of (thanks Madden Mobile!); he even stays up on Thursday, Sunday, and Monday nights listening to the prime-time game using the iPod’s radio in his room. We had no idea until he told me about a play that happened well after he was supposed to be sleeping. But he ‘fessed up and told us what he was doing, and that kind of honesty was great to see. And then there is XX1, who is in raging teenager mode. She knows everything and isn’t interested in learning from the experience of those around her. Very like I was as a teenager. Compared to some of her friends she is a dream – but she’s still a teenager. Aside from her independence kick she has developed a sense of humor that frequently cracks me up. We all like music in the house. And as an old guy I just don’t understand the rubbish the kids listen to nowadays. Twice a year I have to spend a bunch of time buying music for each of them. So I figured we’d try Spotify and see if that would allow all of us to have individual playlists and keep costs at a manageable level. I set up a shared account and we all started setting up our lists. It was working great. Until I was writing earlier this week, jamming to some new Foo Fighters (Sonic Highways FTW), and all of a sudden the playlist switched to something called Dominique by the Singing Nun. Then Spotify goes berserk and cycles through some hardcore rap and dance. I had no idea what was going on. Maybe my phone got possessed or something. Then it clicked – XX1 was returning the favor for all the times I have trolled her over the years. Yup, XX1 hijacked my playlist and was playing things she knew aren’t anywhere near my taste. I sent her a text and she confessed to the prank. Instead of being upset I was very proud. Evidently you can’t live with a prankster and not have some of that rub off. Now I have to start planning my revenge. But for the moment I will just enjoy the fact that my 14-year-old daughter still cares enough to troll me. I know soon enough getting any kind of attention will be a challenge. –Mike Photo credit: “Caution Troll Ahead” originally uploaded by sboneham The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our video podcast, The Firestarter? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail despite Adrian’s best efforts to keep us on track. November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling 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, with our content in all its unabridged glory. And you can get all our research papers too. Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Migration Planning Technical Considerations Solution Architectures Emerging SOC Use Cases Introduction Security and Privacy on the Encrypted Network The Future is Encrypted Newly Published Papers Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection The Future of Security Incite 4 U Flowing downhill: Breaches are ugly. Losing credit card numbers, in particular, can be costly. But after the PCI fines, the banks are always lurking in the background. When Target lost 40 million credit cards, and the banks needed to rotate card numbers and reissue, it isn’t like Target paid for that. And the card brands most certainly will never pay for that. No, they sit there, collect PCI fines (despite Target passing their assessment), and keep the cash. The banks were left holding the bag, and they are sure as hell going to try to get their costs covered. A group of banks just got court approval to move forward with a lawsuit to recover their damages from Target. They are seeking class action status. If the old TJX hack is any indication, they will get it and receive some level of compensation. Resolving all the costs of a breach like this plays out over years, and odds are we will no idea of the true costs for at least 5. Cloud security “grows up”? It’s funny when the hype machine wants to push something faster than it is ready to go. Shimmy argued that Cloud security grows up,

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.