Research

As we discussed in Defining TI, threat intelligence can help detect attacks earlier by benefiting from the misfortune of others and looking for attack patterns being used against higher profile targets. This is necessary because you simply cannot prevent everything. No way, no how. So you need to get better and faster at responding. The first step is improving detection to shorten the window between compromise and discovery of compromise. Before we jump into how – the meat of this series – we need to revisit what your security monitoring process can look like with threat intelligence. TI+SM We will put the cart a bit before the horse. We will assume you already collect threat intelligence as described in the last post. But of course you cannot just wake up and find compelling TI. You need to build a process and ecosystem to get there, but we haven’t described them in any detail yet. But we will defer that discussion a little, until you understand the context of the problem to solve, and then the techniques for systematically gathering TI will make more sense. Let’s dig into specific aspects of the process map: Aggregate Security Data The steps involved in aggregating security data are fairly straightforward. You need to enumerate devices to monitor in your environment, scope out the kinds of data you will get from them, and define collection policies and correlation rules – all described in gory detail in Network Security Operations Quant. Then you can move on to actively collecting data and storing it in a repository to allow flexible, fast, and efficient analysis and searching. Security Analytics The security monitoring process now has two distinct sources to analyze, correlate, and alert on: external threat intelligence and internal security data. Automate TI integration: Given the volume of TI information and its rate of change, the only way to effectively leverage external TI is to automate data ingestion into the security monitoring platform; you also need to automatically update alerts, reports, and dashboards. Baseline environment: You don’t really know what kinds of attacks you are looking for yet, so you will want to gather a baseline of ‘normal’ activity within your environment and then look for anomalies, which may indicate compromise and warrant further investigation. Analyze security data: The analysis process still involves normalizing, correlating, reducing, and tuning the data and rules to generate useful and accurate alerts. Alert: When a device shows one or more indicators of compromise, an alert triggers. Prioritize alerts: Prioritize alerts based on the number, frequency, and types of indicators which triggered them; use these priorities to decide which devices to further investigate, and in what order. Integrated threat intelligence can help by providing additional context, allowing responders to prioritize threats so analysts can investigate the highest risks first. Deep collection: Depending on the priority of the alert you might want to collect more detailed telemetry from the device, and perhaps start capturing network packet data to and from it. This data can facilitate validation and identification of compromise, and facilitate forensic investigation if it comes to that. Action Once you have an alert, and have gathered data about the device and attack, you need to determine whether it was actually compromised or the alert was a false positive. If a device has been compromised you need to escalate – either to an operations team for remediation/clean-up, or to an investigation team for more thorough incident response and analysis. To ensure both processes improve constantly you should learn from each validation step: critically evaluate the intelligence, as well as the policy and/or rule that triggered the alert. For a much deeper discussion of how to Leverage TI in Security Monitoring check out our paper. Useful TI We are trying to detect attacks faster in this use case (rather than working on preventing or investigating them), so the most useful types of TI are strong indicators of problems. Let’s review some data sources from our last post, along with how they fit into this use case: Compromised Devices: The most useful kind of TI is a service telling you there is a cesspool of malware on your network. This “smoking gun” can be identified by a number of different indicators, as we will detail below. But if you can get a product to identify those devices wih analytics on TI data, it saves you considerable effort analyzing and identifying suspicious devices yourself. Of course you cannot always find a smoking gun, so specific TI data types are helpful for detecting attacks: File Reputation: Folks pooh-pooh file reputation, but the fact is that a lot of malware still travels around through the tried and true avenue of file transmission. It is true that polymorphic malware makes it much harder to match signatures, but it’s not impossible; so tracking the presence of files can be helpful for detecting attacks and pinpointing the extent of an outbreak – as we will discuss in detail in our next post. Indicators of Compromise: The shiny new term for an attack signature is indicator of compromise. But whatever you call it an IoC is a handy machine-readable means of identifying registry, configuration, and system file changes that indicate what malicious code does to devices. This kind of detailed telemetry from endpoints and networks enables you to detect attacks as they happen. IP reputation: At this point, given the popularity of spoofing addresses, we cannot recommend making a firm malware/clean judgement based only on IP reputation, but if the device is communicating with known bad addresses and showing other indicators (which can be identified through the wonders of correlation – as a SIEM does) you have more evidence of compromise. C&C Patterns: The last TI data source for this use case is a behavioral analog of IP reputation. You don’t necessarily need to worry about where the device is communicating to – instead you can focus on how it’s communicating. There are known means of polling DNS to find botnet controllers

As we looked back on our research output for the past 2 years it became clear that threat intelligence (TI) has been a topic of interest. We have written no less than 6 papers on this topic, and feel like we have only scratched the surface of how TI can impact your security program. So why the wide-ranging interest in TI? Because security practitioners have basically been failing to keep pace with adversaries for the past decade. It’s a sad story, but it is reality. Adversaries can (and do) launch new attacks using new techniques, and the broken negative security model of looking for attacks you have seen before consistently misses them. If your organization hasn’t seen the new attacks and updated your controls and monitors to look for the new patterns, you are out of luck. What if you could see attacks without actually being attacked? What if you could benefit from the experience of higher-profile targets, learn what adversaries are trying against them, and then look for those patterns in your own environment? That would improve your odds of detecting and preventing attacks. It doesn’t put defenders on an even footing with attackers, but it certainly helps. So what’s the catch? It’s easy to buy data but hard to make proper use of it. Knowing what attacks may be coming at you doesn’t help if your security operations functions cannot detect the patterns, block the attacks, or use the data to investigate possible compromise. Without those capabilities it’s just more useless data, and you already have plenty of that. As we discussed in detail in both Leveraging Threat Intelligence in Security Monitoring and Leveraging Threat Intelligence in Incident Response/Management, TI can only help if your security program evolves to take advantage of intelligence data. As we wrote in the TI+SM paper: One of the most compelling uses for threat intelligence is helping to detect attacks earlier. By looking for attack patterns identified via threat intelligence in your security monitoring and analytics processes, you can shorten the window between compromise and detection. But TI is not just useful for security monitoring and analytics. You can leverage it in almost every aspect of your security program. Our new Applied Threat Intelligence series will briefly revisit how processes need to change (as discussed in those papers) and then focus on how to use threat intelligence to improve your ability to detect, prevent, and investigate attacks. Evolving your processes is great. Impacting your security posture is better. A lot better. Defining Threat Intelligence We cannot write about TI without acknowledging that, with a broad enough definition, pretty much any security data qualifies as threat intelligence. New technologies like anti-virus and intrusion detection (yes, that’s sarcasm, folks) have been driven by security research data since they emerged 10-15 years ago. Those DAT files you (still) send all over your network? Yup, that’s TI. The IPS rules and vulnerability scanner updates your products download? That’s all TI too. Over the past couple years we have seen a number of new kinds of TI sources emerge, including IP reputation, Indicators of Compromise, command and control patterns, etc. There is a lot of data out there, that’s for sure. And that’s great because without this raw material you have nothing but what you see in your own environment. So let’s throw some stuff against the wall to see what sticks. Here is a starter definition of threat intelligence: Threat Intelligence is security data that provides the ability to prepare to detect, prevent, or investigate emerging attacks before your organization is attacked. That definition is intentionally quite broad because we don’t want to exclude interesting security data. Notice the definition doesn’t restrict TI to external data either, although in most cases TI is externally sourced. Organizations with very advanced security programs can do proactive research on potential adversaries and develop proprietary intelligence to identify likely attack vectors and techniques, but most organizations rely on third-party data sources to make internal tools and processes more effective. That’s what leveraging threat intelligence is all about. Adversary Analysis So who is most likely to attack? That’s a good start for your threat intelligence process, because the attacks you will see vary greatly based on the attacker’s mission, and their assessment of the easiest and most effective way to compromise your environment. Evaluate the mission: You need to start by learning what’s important in your environment, so you can identify interesting targets. They usually break down into a few discrete categories – including intellectual property, protected customer data, and business operations information. Profile the adversary: To defend yourself you need to know not only what adversaries are likely to look for, but what kinds of tactics various types of attackers typically use. So figure out which categories of attacker you are likely to face. Types include unsophisticated (using widely available tools), organized crime, competitors, and state-sponsored. Each class has a different range of capabilities. Identify likely attack scenarios: Based on the adversary’s probable mission and typical tactics, put your attacker hat on to figure out which path you would most likely take to achieve it. At this point the attack has already taken place (or is still in progress) and you are trying to assess and contain the damage. Hopefully investigating your proposed paths will prove or disprove your hypothesis. Keep in mind that you don’t need to be exactly right about the scenario. You need to make assumptions about what the attacker has done, and you cannot predict their actions perfectly. The objective is to get a head start on response, narrowing down investigation by focusing on specific devices and attacks. Nor do you need a 200-page dossier on each adversary – instead focus on information needed to understand the attacker and what they are likely to do. Collecting Data Next start to gather data which will help you identify/detect the activity of these potential adversaries in your environment. You can get effective threat intelligence from a number of different

Rich here. Last weekend I ran a local half-marathon. It wasn’t my first, but I managed to cut 11 minutes off my time and set PRs (Personal Record for you couch potatoes) for both the half and a 10K. I didn’t really expect either result, especially since I was out of running for nearly a month due to a random foot injury (although I kept biking). My times have been improving so much lately that I no longer have a good sense of my race paces. Especially b cause I have only run one 10K in the past 3 years that didn’t involve pushing about 100 lbs of kids in a jog stroller. This isn’t bragging – I’m still pretty slow compared to ‘real’ runners. I haven’t even run a marathon yet. These improvements are all personal – not to compare myself to others. I have a weird relationship with running (and swimming/biking). I am most definitely not a natural endurance athlete. I even have the 23andMe genetic testing results to prove it! I’ve been a sprinter my entire life. For you football fans, I could pop off a 4.5 40 in high school (but weighed 135, limiting my career). In lifting, martial arts, and other sports I always had a killer power to weight ratio but lacked endurance for the later rounds. While I have never been a good distance runner running has always been a part of my life. Mostly to improve my conditioning for other sports, or because it was required for NROTC or other jobs. I have always had running shoes in the closet, have always gone through a pair a year, and have been in the occasional race pretty much forever. I even would keep the occasional running log or subscription to Runners World, but I always considered a marathon beyond my capabilities, and lived with mediocre times and improvements. (I swear I read Runners World for the articles, not the pictures of sports models in tight clothes). Heck, I have even had a couple triathlon coaches over the years, and made honest attempts to improve. And I’ve raced. Every year, multiple tris, rides, and runs a year. But then work, life, or travel would interfere. I’d stick to a plan for a bit, get a little better, and even got up to completing a half-marathon without being totally embarrassed. Eventually, always, something would break the habit. That’s the difference now. I am not getting faster because I’m getting younger. I’m getting faster because I stick to the plan, or change the plan, and just grind it out no matter what. Injured, tired, distracted, whatever… I still work out. This is the longest continuous (running) training block I have ever managed to sustain. It’s constant, incremental improvement. Sure, I train smart. I mix in the right workouts. Take the right rest days and adjust to move around injuries. But I. Keep. Moving. Forward. And break every PR I’ve ever set, and am now faster than I was in my 20’s for any distance over a mile. Maybe it’s age. Maybe, despite the Legos and superhero figures on my desk I am achieving s modicum of maturity. Because I use the same philosophy in my work. Learning to program again? Make sure I code nearly every day, even if I’m wiped or don’t have the time. Writing a big paper that isn’t exciting? Write every day; grind it out. Keeping up my security knowledge? Research something new every day; even the boring stuff. Now my life isn’t full of pain and things I hate. Quite the contrary – I may be happier than I’ve ever been. But part of that is learning to relish the grind. To know that the work pays off, even those times it isn’t as fun. Be it running, writing, or security, it always pays off. And, for some of those big races, it means pushing through real pain knowing the endorphins at the end are totally worth it. That, and the post-race beers. Hell, even Michelob Ultra isn’t too bad after 13 miles. Runner’s high and all. Now I need to go run a race with Mike. He’s absolutely insane for taking up running at his age (dude is ancient). Maybe we can go do the Beer Mile together. That’s the one even Lance bailed on after one lap. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences I’m giving a webcast on managing SaaS security later this month for SkyHigh Networks. Rich quoted at TechTarget on hardware security. Favorite Securosis Posts Mike: Firestarter: Full Toddler – The disclosure battles heat up (again) and we wonder when someone is going to change Google’s diaper… Other Securosis Posts Incite 1/21/2015: Making the Habit. New Paper: Security Best Practices for Amazon Web Services. Summary: No Surprises. Incite 1/14/2015: Facing the Fear. Your Risk Isn’t My Risk (Apple Thunderbolt Edition). Friday Summary: Favorite Films of 2014 (Redux). Incite 1/7/2014: Savoring the Moment. Favorite Outside Posts Mike Rothman: Question checklist for reviewing your new marketing materials…. There is so much crappy marketing out there, especially in the security industry. Every marketeer should make sure to go through Godin’s list before sending anything out to the market. Pepper: The flood through the crack in the Great Firewall. The Iconfactory effectively DDoSed by China. Rich: Will Sharing Cyberthreat Information Help Defend the United States? Good analysis. We can’t legislate ourselves out of the cybersecurity mess, but if all we do is bitch on Twitter, we sure won’t get anywhere. Richard is one of the few trying to really engage on the issue and help navigate the complexity. Dave Lewis: 3 Problems With UK PM Cameron’s Crypto Proposal. Nope, it isn’t just in the US. Rich #2: A Spy in the Machine. This is one reason consumer privacy and security, without back doors for governments is so important. Research Reports and Presentations Security Best Practices for Amazon Web Services. Securing Enterprise Applications. Secure Agile Development. Trends in

Over halfway through January (already!), how are those New Year’s resolutions going? Did you want to lose some weight? Maybe exercise a bit more? Maybe drink less, or is that just me? Or have some more fun? Whatever you wanted to do, how is that going? If you are like most the resolutions won’t make it out of January. It’s not for lack of desire, as folks that make resolutions really want to achieve the outcomes. In many cases the effort is there initially. You get up and run or hit the gym. You decline dessert. You sit with the calendar and plan some cool activities. Then life. That’s right, things are busy and getting busier. You have more to do and less to do it with. The family demands time (as they should) and the deadlines keep piling up. Travel kicks back in and the cycle starts over again. So you sleep through the alarm a few days. Then every day. The chocolate lava cake looks so good, so you have one. You’ll get back on the wagon tomorrow, right? And then it’s December and you start the cycle over. That doesn’t work very well. So how can you change it? What is the secret to making a habit? There is no secret. Not for me, anyway. It’s about routine. Pure and simple. I need to get into a routine and then the habits just happen. For instance I started running last summer. So 3 days a week I got up early and ran. No pomp. No circumstance. Just get up and run. Now I get up and freeze my ass off some mornings, but I still run. It’s a habit. Same process was used when I started my meditation practice a few years back. I chose not to make the time during the day because I got mired in work stuff. So I got up early. Like really early. I’m up at 5am to get my meditation done, then I get the kids ready for school, then I run or do yoga. I have gotten a lot done by 8am. That’s what I do. It has become a routine. And a routine enables you to form a habit. Am I perfect? Of course not, and I don’t fret when I decide to sleep in. Or when I don’t meditate. Or if I’m a bit sore and skip my run. I don’t judge myself. I let it go. What I don’t do is skip two days. Just as it was very hard to form my habits of both physical and mental practice, it is all too easy to form new less productive habits. Like not running or not meditating. That’s why I don’t miss two days in a row. If I don’t break the routine I don’t break the habit. And these are habits I don’t want to break. –Mike Photo credit: “Good, Bad Habits” originally uploaded by Celestine Chua 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. January 15 – Full Toddler 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. 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 Best Practices for AWS Security 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 Advanced Endpoint and Server Protection The Future of Security Incite 4 U Doing attribution right… Marcus kills it in this post on why attribution is hard. You need to have enough evidence, come up with a feasible motive, corroborate the data with other external data, and build a timeline to understand the attack. But the post gets interesting when Marcus discusses how identifying an attacker based upon TTPs might not work very well. Attackers can fairly easily copy another group’s TTPs to blame them. I think attribution (at least an attempt) can be productive, especially as part of adversary analysis. But understand it is likely unreliable; if you make life and death decisions on this data, I don’t expect it to end well. – MR The crypto wars rise again: Many of you have seen this coming, but in case you haven’t we are hitting the first bump on a rocky road that could dead end in a massive canyon of pain. Encryption has become a cornerstone of information security, used for everything from secure payments to secure communications. The problem is that the same tools used to keep bad guys out also keep the government out. Well, that’s only a problem because politicians seem to gain most of

I could probably write a book on AWS security at this point, except I don’t have the time, and most of you don’t have time to read it. So I wrote a concise paper on the key essentials to get you started – including the top four things to do in the first five minutes with a new AWS account. Here is an excerpt: Amazon Web Services is one of the most secure public cloud platforms available, with deep datacenter security and many user-accessible security features. Building your own secure services on AWS requires properly using what AWS offers, and adding additional controls to fill the gaps. Never forget that you are still responsible for everything you deploy on top of AWS, and for properly configuring AWS security features. AWS is fundamentally different from a virtual datacenter (private cloud), and understanding these differences is key for effective cloud security. This paper covers the foundational best practices to get you started and help focus your efforts, but these are just the beginning of a comprehensive cloud security strategy. The paper has a [permanent home]((https://securosis.com/research/publication/security-best-practices-for-amazon-web-services). Or you can directly download the PDF. I would especially like to thank AlienVault for licensing this paper. Remember companies that license our content don’t get to influence or steer it (outside of submitting comments like anyone else), but their support means we get to release it all for free. Share:

Testing tags Share:

Yes, people, the disclosure debate is still alive and kicking. But now it is basically a pissing match between two of the largest tech companies. With Google setting rigid deadlines, and Microsoft stuck on their rigid schedule, who will win? Grab the popcorn as we talk about egos, internal inconsistencies, and why putting the user first is so damn hard. Watch or listen below: Share:

Rich here, First a quick note. I will be giving a webcast on managing SaaS security later this month. I am about to start writing more on the Cloud Security Gateway market and new techniques for dealing with SaaS. I planned to write something irreverent in this week’s Summary (like my favorite films), but it has been an odd week in the security world. I expect the consequences to play out over the next decade. I should probably write this up as a dedicated post, but my thoughts are shifting around so much that I am not sure my ideas are ready to stand on their own. Before I go into this, please keep in mind that the security ‘world’ is a collection of different groups. Tribes might be a better word. But across all subgroups we tend to be skeptical and critical. That is quite healthy, considering what we do, but can easily turn negative and self-defeating. This is especially true when we engage with society at large. We are, on the whole, the pain-in-the-ass cousin who shows up at the holidays and delights in challenging and debating the rest of the family long past the point where anyone else cares. Yeah, we get it, you caught me in a logical fallacy because I like my new TV but bitched at you for not recycling your beer cans. You win. Now pass the stuffing and STFU. Also factor in our inherent bias against anyone who does things others don’t understand. (Hat tip to Rob Graham for first introducing me to this concept). We have a long lineage that looks something like heretic > witch > egghead > nerd > geek > hacker. No, not everyone reading this is a hacker, but society at large cannot really differentiate between specific levels of technical wizardry. This is especially true for those of you who play with offensive security, no matter how positive your contributions. Back to the main story, which is shorter than all this preamble. This week the White House proposed some updates to our computer security laws. Some good, some bad. The Twitter security echo chamber exploded a bit, with much hand-wringing over how this could lead to bad legal consequences – not only for anyone working legitimately in offensive security; it could also create all sorts of additional legal complexities with chilling effects. There are actually a bunch of proposals circulating, which would affect not only cybersecurity but general Internet usage. From the UK wanting to ban encryption, to mandating DNSSEC, to the FBI wanting to ban effective encryption, to… well, everyone wanting to ban encryption, file sharing, and… stuff. Many in the security world seem to feel we should have some say over these laws and policies. But we have mostly seen vendors lobby to have their products mandated (and then shrug when people using them get hacked), professional groups pushing to have their training or certifications mandated, and the occasional researcher treated like a dancing monkey for the cameras. And political leaders probably don’t see much distinction between any of these and the big Internet protests that their Hollywood funders all tell them are just criminals who want to watch movies free. We have mostly done this to ourselves. We are fiercely independent, so it isn’t like we speak with a single voice. We can’t even decide what constitutes a “security professional”. Then we keep shooting ourselves in the foot by demanding evidence from law enforcement and intelligence agencies on things like the Sony hack. And, er, telling the FBI they are wrong rarely works out well. I am not telling anyone not to do or say what they want. Just keep in mind how the world views you (as witches), and how much technology just scares people, no matter how much they love their iPhones. And if you want to affect politics you need to play politics. Twitter ain’t gonna cut it. Seriously, no one likes that smarty-pants cousin (or in-law, in my case). And if any lobbyists are reading this, please fix the Kinderegg ban first, then get started on defending encryption. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences As I mentioned, I am presenting on managing SaaS security on the 29th. Favorite Securosis Posts Mike Rothman: Your Risk Isn’t My Risk. It is always important to consider likelihood when looking at new attacks. Rich puts the latest in context. Rich: Incite 1/14/2015: Facing the Fear. Because that was my only other choice. I mean, it’s still a good post, but it isn’t like I had an option. Other Securosis Posts And now you see why I had to pick Mike’s post. Favorite Outside Posts Adrian Lane: The importance of deleting old stuff. Honestly, it’s not as valuable as you think, and it is likely to cause harm in the long run. Mike Rothman: The Stunning Scale of AWS. I remember Rich mentioning some of these stats after he got back from the AWS conference in 2013. It is shocking to see this documented, and to understand that when trying to really scale something… commercial products just won’t cut it. Really interesting. Rich: Encryption is Not the Enemy. Dennis lays it out nicely, not that I expect the latest round of crypto wars to end any time soon. 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 Obama’s War on Hackers. Money quote: “This War on Hackers is likely to be no more effective than the War on Drugs”. Gitrob Combs Github Repositories for Secret Company Data. Looks super useful. President

Some folks just naturally push outside their comfort zones as a matter of course. I am one of them. Others only do things that are comfortable, which is fine if it works for them. I believe that while you are basically born with a certain risk tolerance, you can be taught to get comfortable with pushing past your comfort zone. For example, kids who are generally shy will remain more comfortable holding up the wall at a social event, but can learn to approach people and get into the mix. It’s tough at first but you figure it out. There is always resistance the first few times you push a child beyond what they are comfortable with, and force them to try something they don’t think they can do. But I believe it needs to happen. It comes back to my general philosophy that limitations exist only in our minds, and you can move past those limitations once you learn to face your fear. The twins’ elementary school does a drama production every year. XX1 was involved when she was that age, and XX2 was one of the featured performers last year. We knew that she’d be right there auditioning for the big role, and she’d likely get one of them (as she did). But with the Boy we weren’t sure. He did the hip hop performance class at camp so he’ll perform, but that’s a bit different than standing up and performing in front of your friends and classmates. Though last year he did comment on how many of his friends were in the show, and he liked that. We were pleased when he said he wanted to try out. The Boss helped him put together both a monologue and a song to sing for the audition. He knew all the words, but when it came time to practice he froze up. He didn’t want to do it. He wanted to quit. That was no bueno in my book. He needed to try. If he didn’t get a part, so be it. But he wasn’t going to back out because he was scared. He needed to push through that fear. It’s okay to not get the outcome you hope for, but not to quit. So we pushed him. There were lots of tears. And we pushed some more. A bit of feet stomping at that point. So we pushed again. He finally agreed to practice for us and then to audition after we wore him out. Sure, that was a little heavy-handed, but I’m okay with it because we decided he needed to at least try. The end result? Yes, he got a part. I’m not sure how much he likes the process of getting ready for the show. We’ll see once he gets up on stage and performs for everyone whether it’s something he will want to do again. But whether he does it again doesn’t matter. He can always say he tried, even when he didn’t want to. That he didn’t let fear stop him from doing something. And that’s the most important lesson of all. –Mike Photo credit: “Faces of fear!” originally uploaded by John Seb Barber 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 Full discraposure: Google discovers a bug in a Microsoft product. Google has a strict 90-day policy to disclose, no matter what. Microsoft says, “Hey, we have a fix ready to go on Patch Tuesday, can we get a few extra days?” but Google releases anyway. I’m sorry, but who does that help? Space Rogue summed it up best; he has a long history in the disclosure debate. In his words, “The entire process has gotten out of hand. The number one goal here should be getting stuff fixed because getting stuff fixed helps protect the user, it helps defeat the bad guys and it helps make the world a better place.” Another great quote is: “And so the disclosure debate continues unabated for over a hundred years. With two of the giants in our industry acting like spoiled children we as security professionals must take the reigns

Last Friday I wrote an article on the Thunderstrike proof of concept attack against Macs. I won’t spend any more time analyzing it but I think it’s valuable as an example of risk assessment. The short version is… it’s a creative attack that, if you have physical access to a Mac, could allow you to completely compromise it by merely connecting external hardware and triggering a reboot. The attack is against the firmware, and even removing the Mac’s hard drive leaves it infected. The Thunderstrike proof-of-concept takes advantage of this trust to replace the contents of the Mac’s boot ROM with the attacker’s own code, effectively embedding it into the Mac’s hardware and making it impossible to remove using standard techniques. The attack works because Apple relies on software checks to confirm the firmware is valid, and Hudson developed techniques to circumvent those checks (and even replace the encryption key). Apple is taking this seriously; it is already fixed on new hardware (Retina iMacs and new Mac Minis), and a further fix for older hardware is coming soon according to my sources (sooner than you probably think). But that is only a partial fix because an attacker can still downgrade the firmware and then execute the attack, although that doubles the time requirement. In my article I made clear that very few people need to worry about this now: While all Macs are technically vulnerable to the Thunderstrike attack, few TidBITS readers face any immediate risk. The attack is highly targeted – someone needs both physical access to your Mac and time to reboot it and reinstall the firmware. On top of that, it isn’t like everyone is walking around with maliciously modified Thunderbolt dongles. So why write it up? Why talk about an attack that has to be designed for the specific hardware version you are using, requires physical control of your device, and can’t realistically spread on any wide basis? Because I’m at risk, as are many readers here at Securosis. For the TidBITS crowd I mostly wanted to assuage concerns and compensate for the usual spate of over-hyped stories. For Securosis? Some of you need to worry. I have direct reports of executives and security pros being compromised when their hardware leaves their control; typically when traveling internationally, usually to one of a few countries. (Make that mostly one country). BTW, I don’t have any reports of these attacks on Macs, and I am very interested if you have a confirmed report, even if you can’t provide details. Starting in about 2008 I started paying a lot more attention to physical control over my computers and mobile devices under certain circumstances (I am not counting hacker conferences – I have always kept hard control at those). The reports coming in from clients indicated that customs and hotel rooms were not safe places to lose physical control. I even stopped traveling to China with devices I was worried about, which did inhibit my ability to get work done while there. Thunderstrike itself isn’t a big deal. It’s super interesting, but damn low on the risk list. Mostly. As a proof of concept it is incredibly educational, and some of you, especially readers of this site, need to pay attention to these kinds of attacks (for yourselves or your organizations). That’s why I like this story as a good example of understanding risk. For one publication, TidBITS, I wrote it up to debunk fear. For another, here, I am writing it up as a warning of real risk, if you fall into the right bucket. [Ed: The presentation is also remarkably readable – much easier to understand than I expected for something this complicated. –cp] Share: