Research

If you caught my weekend rantings on Twitter, I had some free time this past weekend. The Boss was on a girl’s weekend. The kids are away at camp. And I had a meeting with a client first thing Monday morning. So I could have stayed in the ATL and taken an evening flight out. Or I could fly out first thing in the morning and find a way to get my blood pumping. Shockingly enough, I chose the latter. There is nothing better to get your blood moving than pulling some Gs on a cool roller coaster. I love roller coasters. The anticipation of the drop. The screaming of the folks around you. That exhilaration is hard to match. At least for me. Until it isn’t. Maybe I was just very calm on Sunday. But my heart rate hardly moved on the first wooden coaster. It was fast. It was fun. But it wasn’t scary. The two-loop two-corkscrew ride barely moved the needle either. Maybe I am just numb to coasters. Sure it’s fun, but where is the rush? The stand-up coaster was cool. That was pretty exciting. As was the ‘flying’ coaster, where you ride on the outside of the track with your feet dangling. But there was still something missing. Then I saw it. The free fall ride. I am not a big fan of free fall rides. I’ll take loops, drops, and corkscrews every time. I rode the Tower of Terror at Disney with the girls, but that’s more because I needed to. I had to represent in front of my girls. Sure it was fun, but it’s not my favorite. But in need of an adrenaline rush, I figured it was time. Time to conquer my discomfort and just drop. So I stood in line and within a couple minutes I was ascending 200-something feet in the air. The view was beautiful. The 16-year-old running the ride started chirping something about the ride being broken. That we’d need to descend slowly. But I wasn’t born yesterday. I took a deep breath and got ready. Then I dropped. For 4 seconds anyway. It took my breath away, but I lived. My adrenaline spiked. My heart rate elevated. I felt alive! And I conquered the free fall. It was a good day. It’s not great to have to travel for work on a Sunday, but if you need to. at least make sure you have some fun. –Mike Photo credit: “Drop zone” originally uploaded by Alan Teo 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 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. 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 May 5 – There Is No SecDevOps April 28 – The Verizon DBIR April 14 – Three for Five March 24 – The End of Full Disclosure 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. The Security Pro’s Guide to Cloud File Storage and Collaboration Core Security Features Overview and Baseline Security Introduction Leveraging Threat Intelligence in Incident Response/Management Quick Wins The (New) Incident Response & Management Process Model Threat Intelligence + Data Collect = Responding Better Really Responding Faster Introduction Trends in Data Centric Security Deployment Models Tools Introduction Use Cases Understanding Role-based Access Control Advanced Concepts Introduction NoSQL Security 2.0 Understanding NoSQL Platforms Introduction Newly Published Papers The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection Defending Against Network-based DDoS Attacks Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Incite 4 U The Imprudence of Clouds: The SNL skit “Common Knowledge” was a game show where the ‘right’ answer to a question was not the factual answer, but whatever popular answer the studio audience thought was right. That’s what ran through my mind when Robert Graham pointed out that the fact that Some in cybersec keep claiming that open-source is inherently more secure or trustworthy than closed-source does not make it true. Rob’s good like that – poking at so-called “common knowledge”. And based on Sonatype’s just-completed open source survey, clearly developers believes this as well. I would not yet call it a cliche – only a couple years ago enterprises prohibited open source as untrustworthy – but Rob has a good point. In many cases open source code is not being reviewed, and while I see some open source code scanning, open code can be just as bad as commercial software: poor usability, bugs, and vulnerabilities. There is crap software all over the place. Whether you pay for it or not. – AL DDoS: Coming soon to an amateur near you: It was only a matter of time. But it looks like DDoS is about to hit the masses. Between folks using fake Googlebots to blast a site, packaged DDoS kits available for $500, and DDoS bots on Amazon taking advantage of a defect in ElasticSearch, DDoS attacks are becoming more accessible to hackers

I really like this story about ULTRA Testing, which hires folks on the autism spectrum to perform software testing. The CEO makes a great point here: As a result, he maintains, employers around the world are leaving huge pools of talent untapped because they don’t know where to look. Finding enough good people remains the bane of most CISO types. Everyone is looking at intern programs to find talented kids coming out of university. Everyone is recruiting military folks as they roll off their tours of duty. There still aren’t enough. As I have written a number of times, as an industry we need to be more creative. We must find high-potential folks and invest in them. ULTRA does this for their testing business, knowing that highly functioning people on the spectrum can do the job – given the right accommodations. This is especially true of the 400,000 autism spectrum members deemed to be high-functioning, meaning they have strong visual and spatial relations skills and average or above-average IQs. Research suggests they can have heightened abilities in pattern recognition and logical reasoning, but many adults living with autism and Asperger’s are thwarted by job interviews that test their limited social skills and workplace environments that are unprepared for their literal-mindedness and unrelenting attention to detail. Why can’t this work for security? Much the job is repetitious. Unless you want to be a senior person there isn’t much need to work with many folks. Instead of having your HR group say “that won’t work” because someone doesn’t check all the boxes on the job spec, maybe you can say “it’s worth a try.” Of course you would have to be willing to stick your neck out. You’d have to be willing to run interference for some folks who have issues in a traditional work environment. You would need the courage to make it happen. Not everyone is up to that, and that’s okay given the number of other battles you need to fight daily. But if you spend most of your time bitching about how you can’t fill your openings, maybe it’s time to start thinking across a broader spectrum. Just maybe. Photo credit: “Energy Saver Light Bulb” originally uploaded by James Bowe Share:

In an uncommon occurrence we have updated one of our papers within a year of publication. As mentioned in the latest version of our Endpoint Security Buyer’s Guide, mobile devices are just additional endpoints that need to be managed like any other device. But it became clear that we needed to dig a bit deeper into securing mobile endpoints. Our updated and revised 2015 Endpoint and Mobile Security Buyer’s Guide updates our research on key endpoint management functions including anti-malware, patch and confirmation management, and device control. Additionally we dug a lot deeper into mobile security and managing BYOD. The reality is that securing endpoints hasn’t gotten any easier. Employees still click things and attackers have gotten better at evading perimeter defenses and obscuring attacks. Humans, alas, remain gullible and flawed. Regardless of any training you provide employees, they continue to click stuff, share information, and fall for simple social engineering attacks. So endpoints remain some of the weakest links in your security defenses. As much as the industry wants to discuss advanced attacks and talk about how sophisticated adversaries have become, the simple truth remains that many successful attacks result from simple operational failures. So yes, you do need to pay attention to advanced malware protection tactics, but if you forget about the fundamental operational aspects of managing endpoint hygiene the end result will be the same. To provide some context, we have said for years that management is the first problem users solve when introducing a new technology. Security becomes a consideration only after management issues are under control. This is the key reason we are adding a bunch of new content about securing mobile devices. Many organizations have gotten their arms around managing these devices, so now they are focusing their efforts on security and privacy – especially around apps running on those devices. What has not changed is our goal for this guide: to provide clear buying criteria for those of you looking at endpoint security solutions in the near future. Visit the permanent landing page Direct Download (PDF): The 2015 Endpoint and Mobile Security Buyer’s Guide We would like to thank Lumension Security for licensing this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our work. Share:

The best way to understand how threat intelligence impacts your incident response/management process is to actually run through an incident scenario with commentary to illustrate the concepts. For simplicity’s sake we assume you are familiar with our recommended model for an incident response organization and the responsibilities of the tier 1, 2, and 3 response levels. You can get a refresher back in our Incident Response Fundamentals series. For brevity we will use an extremely simple high-level example of how the three response tiers typically evaluate, escalate, and manage incidents. If you are dealing with an advanced adversary things will be neither simple nor high-level. But this provides an overview of how things come together. The Trigger Intellectual property theft is a common mission for advanced attacker, so that will be our scenario. As we described in our Threat Intelligence in Security Monitoring paper, you can configure your monitoring system to look for suspicious IP ranges from your adversary analysis. But let’s not put the cart before the horse. Knowing you have valuable IP (intellectual property), you can infer that a well-funded adversary (perhaps a nation-state or a competitor) has a great interest in that information. So you configure your monitoring process to look for connections to networks where those adversaries commonly hang out. You get this information from a threat intelligence service and integrate it automatically into your monitoring environment, so you are consistently looking for network traffic that indicates a bad scene. Let’s say your network monitoring tool fires an alert for an outbound request on a high port to an IP range identified as suspicious via threat intelligence. The analyst needs to validate the origin of the packet so he looks and sees the source IP is in Engineering. The tier 1 analyst passes this information along to a tier 2 responder. Important intellectual property may be involved and he suspects malicious activity, so he also phones the on-call handler to confirm the potential seriousness of the incident and provides a heads-up. Tier 2 takes over and the tier 1 analyst returns to other duties. The outbound connection is the first indication that something may be funky. An outbound request very well might indicate an exfiltration attempt. Of course it might not but you need to assume the worst until proven otherwise. Tracing it back to a network that has access to sensitive data means it is definitely something to investigate more closely. The key skill at tier 1 is knowing when to get help. Confirming the alert and pinpointing the device provide the basis for the hand-off to tier 2. Triage Now the tier 2 analyst is running point on the investigation. Here is the sequence of steps this individual will take: The tier 2 analyst opens an investigation using the formal case process because intellectual property is involved and the agreed-upon response management process requires proper chain of custody when IP is involved. Next the analyst begins a full analysis of network communications from the system in question. The system is no longer actively leaking data, but she blocks all traffic to the suspicious external IP address on the perimeter firewall by submitting a high-priority firewall management request. After that change is made she verifies that traffic is in fact blocked. The analyst does run the risk of alerting the adversary, but stopping a potential IP leak is more important than possibly tipping off an adversary. She starts to capture traffic to/from the targeted device, just so a record of activity is maintained. The good news is all the devices within engineering already run endpoint forensics on their devices, so there will be a detailed record of device activity. The analyst then sets an alert for any other network traffic to the address range in question to identify other potentially compromised devices within the organization. At this point it is time to call or visit the user to see whether this was legitimate (though possibly misguided) activity. The user denies knowing anything about the attack or the networks in question. Through that discussion she also learns that specific user doesn’t have legitimate access to sensitive intellectual property, even though they work in engineering. Normally this would be good news but it might indicate privilege escalation or that the device is a staging area before exfiltration – both bad signs. The Endpoint Protection Platform (EPP) logs for that system don’t indicate any known malware on the device and this analyst doesn’t have access to endpoint forensics, so she cannot dig deeper into the device. She has tapped out her ability to investigate so she notifies her tier 3 manager of the incident. While processing the hand-off she figures she might as well check out the network traffic she started capturing at the first attack indication. The analyst notices outbound requests to a similar destination from one other system on the same subnet, so she informs incident response leadership that they may be investigating a serious compromise. By mining some logs in the SIEM she finds that the system in question logged into to a sensitive file server it doesn’t normally access, and transferred/copied entire directories. It will be a long night. As we have mentioned, tier 2 tends to focus on network forensics and fairly straightforward log analysis because they are usually the quickest ways to pinpoint attack proliferation and gauge severity. The first step is to contain the issue, which entails blocking traffic to the external IP to temporarily eliminate any data leakage. Remember you might not actually know the extent of the compromise but that shouldn’t stop you from taking decisive action to contain the damage as quickly as possible – per the guidance laid down when you built designed the incident management process. Tier 3 is notified at this point – not necessarily to take action, but so they are aware there might be a more serious issue. Proactive communication streamlines escalation. Next the tier 2 analyst needs to assess the extent of

One of the things I most enjoy when the kids are at camp is being able to follow my natural rhythms. During the school year things are pretty structured. Get up at 5, do my meditation, get the kids ready for school, do some yoga/exercise, clean up, and get to work. When I’m on the road things are built around the business day, when I’m running around from meeting to meeting. But during the summer, when I’m not traveling I can be a little less structured and it’s really nice. I still get up pretty early, but if I want to watch an episode of Game of Thrones at 10am I will. If I want to do some journaling at 3pm, I will. If I feel like starting the Incite at 9pm I’ll do that too. I tend to be pretty productive first thing in the morning, and then later in the day. Not sure why but that’s my rhythm. I have always tried to schedule my work calls in the early afternoon when possible, when I have a bit less energy, and needing to be on during the call carries me through. I do a lot of my writing pretty late at night. At least I have been lately. That’s when inspiration hits, and I know better than to mess with things when it’s flowing. Of course when the kids come home rhythms be damned. Seems the school board doesn’t give a rat’s ass about my rhythms. Nor does the dance company or the lax team. The kids need to be there when they need to be there. So I adapt and I’m probably not as efficient as I could be. But it’s okay. I can still nod off at 11am or catch a matinee at noon if I feel like it. Just don’t tell The Boss, Rich, or Adrian – they think I’m always diligently working. That can be our little secret… –Mike Photo credit: “Mystic Rhythms signage” originally uploaded by Julie Dennehy 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 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. 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 May 5 – There Is No SecDevOps April 28 – The Verizon DBIR April 14 – Three for Five March 24 – The End of Full Disclosure 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. The Security Pro’s Guide to Cloud File Storage and Collaboration Introduction Leveraging Threat Intelligence in Incident Response/Management The (New) Incident Response & Management Process Model Threat Intelligence + Data Collect = Responding Better Really Responding Faster Introduction Endpoint Security Management Buyer’s Guide (Update) Mobile Endpoint Security Management Trends in Data Centric Security Deployment Models Tools Introduction Use Cases Understanding Role-based Access Control Advanced Concepts Introduction NoSQL Security 2.0 Understanding NoSQL Platforms Introduction Newly Published Papers Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection Defending Against Network-based DDoS Attacks Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Eliminating Surprises with Security Assurance and Testing Incite 4 U No executive access, what? Something doesn’t compute about this Ponemon survey claiming 31% of organizations surveyed never speak to their senior team about security? And 40% in the UK? I don’t believe it. Maybe those respondents had one pint too many. Any regulated organization needs to communicate about security. Any company looking to acquire cyber liability insurance needs to communicate about security. Any friggin’ company with anything to steal needs to communicate about security. Now, is that communication effective? Probably not. Should it happen more often? Absolutely. But I don’t buy not at all – that sounds like hogwash. But it makes for good click-thru numbers, and I shouldn’t forget vendors need to feed the pageview beast. – MR And they’re off! Starbucks is launching a general purpose payment app, so you can not only buy coffee, but use the app for other retailers as well. Sure, it seems odd to use a Starbucks app to buy something like airline tickets, but the race to own the customer shopping experience is heating up! Currently it’s Visa by a nose – they both continue to push support for their mobile wallet and aggressively engage merchants to support single-button checkout in Europe. Just to pat myself on the back a bit, a year ago I said that Visa was gunning to be an Identity Provider, and that is essentially what this is. Merchant app? Merchant wallet? Payment provider wallet? Don’t like any of those options? How about one embedded into your phone? For years telcos have been working with phone manufacturers to embed a ‘secure element’ to manage secure communications, VPN, and secure payment linked directly to your cell account. Fortunately that cat herding exercise is going nowhere fast – would you choose AT&T as your bank? What could go wrong with that? And don’t forget about new payment approaches either. Host Card Emulation (e.g., a virtual secure element) running

Now that we have the inputs (both internal and external) to our incident response/management process we are ready to go operational. So let’s map out the IR/M process in detail to show where threat intelligence and other security data allows you to respond faster and more effectively. Trigger and Escalate You start the incident management process with a trigger that kicks off the incident response process, and the basic information you gather varies based on what triggered the alert. You may get alerts from all over the place, including any of your monitoring systems and the help desk. Nobody has a shortage of alerts – the problem is finding the critical alerts and taking immediate action. Not all alerts require a full incident response – much of what you already deal with on a day-to-day basis is handled by existing security processes. Incident response/management is about those situations that fall outside the range of your normal background noise. Where do you draw the line? That depends entirely on your organization. In a small business, a single system infected with malware might require a response because all devices have access to critical information. But a larger company might handle the same infection within standard operational processes. Regardless of where the line is drawn, communication is critical. All parties must be clear on which situations require a full incident investigation and which do not before you can decided whether to pull the trigger or not. For any incident you need a few key pieces of information early to guide next steps. These include: What triggered the alert? If someone was involved or reported it, who are they? What is the reported nature of the incident? What is the reported scope of the incident? This is basically the number and nature of systems/data/people involved. Are any critical assets involved? When did the incident occur, and is it ongoing? Are there any known precipitating events for the incident? Is there a clear cause? Gather what you can from this list to provide an initial picture of what’s going on. When the initial responder judges an incident to be more serious it’s time to escalate. You should have guidelines for escalation, such as: Involvement of designated critical data or systems. Malware infecting a certain number of systems. Sensitive data detected leaving the organization. Unusual traffic/behavior that could indicate an external compromise. Once you escalate it is time to assign an appropriate resource, request additional resources if needed, and begin the response with triage. Response Triage Before you can do anything, you will need to define accountabilities among the team. That means specifying the incident handler, or the responsible party until a new responsible party is defined. You also need to line up resources to help based on answers to the questions above, to make sure you have the right expertise and context to work through the incident. We have more detail on staffing the response in our Incident Response Fundamentals series. The next thing to do is to narrow down the scope of data you need to analyze. As discussed in the last post, you spend considerable time collecting events and logs, as well as network and endpoint forensics. This is a tremendous amount of data so narrowing down the scope of what you investigate is critical. You might filter on the segments attacked, or logs of the application in question. Perhaps you will take forensics from endpoints at a certain office if you believe the incident was contained. This is all to make the data mining process manageable. With all this shiny big data technology, do you need to actually move the data? Of course not, but you will need flexible filters so you can see only items relevant to this incident in your forensic search results. Time is of the essence in any response, so you cannot afford to get bogged down with meaningless and irrelevant results as you work through collected data. Analyze Once you have filters in place you will want to start analyzing the data to answer several questions: Who is attacking you? What tactics are they using? What is extent of the potential damage? You may have an initial idea based on the alert that triggered the response, but now you need to prove that hypothesis. This is where threat intelligence plays a huge role in accelerating your response. Based on the indicators you found, a TI service can help identify a potentially responsible party. Or at least a handful of them. Every adversary has their preferred tactics, and whether through adversary analysis (discussed in Really Responding Faster) or actual indicators, you want to leverage external information to understand the attacker and their tactics. It is a bit like having a crystal ball, allowing you to focus your efforts and what the attacker likely did, and where. Then you need to size up or scope out the damage. This comes down to the responder’s initial impressions as they roll up to the scene. The goal here is to take the initial information provided and expand on it as quickly as possible to determine the true extent of the incident. To determine scope you will want to start digging into the data to establish the systems, networks, and data involved. You won’t be able to pinpoint every single affected device at this point – the goal is to get a handle on how big a problem you might be facing, and generate some ideas on how to best mitigate it. Finally, based on the incident handler’s initial assessment, you need to decide whether this requires a formal investigation due to potential law enforcement impact. If so you will need to start thinking about chain of custody for the evidence so you can prove the data was not tampered with, and tracking the incident in a case management system. Some organizations treat every incident this way, and that’s fine. But not all organizations have the resources or capabilities for that, in

Our last post defined what is needed to Really Respond Faster, so now let’s peel back the next layer of the onion to delve into collecting data that will be useful for investigation, both internally and externally. This starts with gathering threat intelligence to cover the external side. It also involves a systematic effort to gather forensic information from networks and endpoints while leveraging existing security information sources including events, logs, and configurations. External View: Integrating Threat Intel In the last post we described the kinds of threat intelligence at your disposal and how they can assist your response. But that doesn’t explain how you can gather this information or where to put it so it’s useful when you are knee-deep in response. First let’s discuss the aggregation point. In Early Warning System we described a platform to aggregate threat intelligence. Those concepts are still relevant to what you need the platform to do. You need the platform to aggregate third-party intelligence feeds, and be able to scan your environment for indicators to find potentially compromised devices. To meet these goals a few major capabilities stand out: Open: The first job of any platform is to facilitate and accelerate investigation so you need the ability to aggregate threat intelligence and other security data quickly, easily, and flexibly. Intelligence feeds are typically just data (often XML), and increasingly distributed in industry-standard formats such as STIX – making integration relatively straightforward. Scalable: You will collect a lot of data during investigation, so scalability is essential. Keep in mind the difference between data scalability (the amount of stuff you can store) and computational scalability (your ability to analyze and search the collected data). Flexible search: Investigations still involve quite a bit of art, rather than being pure formal science. As tools improve and integrated threat intelligence helps narrow down targets for investigation, you will be less reliant on forensic ‘artists’. But you will always be mining collected data and searching for attack indications, regardless of the capabilities of the person with their hands on the keyboard. So your investigation platform must make it easy to search all your data sources, and then identify assets at risk based on what you found. The key to making this entire process run is automation. Yes, we at Securosis talk about automation a whole lot these days, and there is a reason for that. Things are happening too quickly for you to do much of anything manually, especially in the heat of an investigation. You need the ability to pull threat intelligence in a machine-readable format, and then pump it into an analysis platform without human intervention. Simple, right? So let’s dig into the threat intelligence sources to provide perspective on how to integrate that data into your platform. Compromised devices: The most actionable intelligence you can get is still a clear indication of compromised devices. This provides an excellent place to begin your investigation and manage your response. There are many ways you might conclude a device is compromised. The first is by seeing clear indicators of command and control traffic in the device’s network traffic, such as DNS requests whose frequency and content indicate a domain generating algorithm (DGA) for finding botnet controllers. Monitoring traffic from the device can also show files or other sensitive data being transmitted by the device, indicating exfiltration or (via network traffic analysis) a remote access trojan. Malware indicators: As described in our Malware Analysis Quant research, you can build a lab and perform both static and dynamic analysis of malware samples to identify specific indicators of how the malware compromises devices. This is not for the faint of heart – thorough and useful analysis requires significant investment, resources, and expertise. The good news is that numerous commercial services now offer those indicators in a format you can use to easily search through collected security data. Adversary networks: Using IP reputation data broken down into groups of adversaries can help you determine the extent of compromise. If during your initial investigation you find malware typically associated with Adversary A, you can then look for traffic going to networks associated with that adversary. Effective and efficient response requires focus, so knowing which of your compromised devices may have been compromised in a single attack helps you isolate and dig deeper into that attack. Given the demands of gathering sufficient information to analyze, and the challenge of detecting and codifying appropriate patterns and indicators of compromise, most organizations look for a commercial provider to develop and provide this threat intelligence. It is typically packaged as a feed for direct integration into incident response/monitoring platforms. Wrapping it all together we have the process map below. The map encompasses profiling the adversary as discussed in the last post, collecting intelligence, analyzing threats, and then integrating threat intelligence into the incident response process. Internal View: Collecting Forensics The other side of the coin is making sure you have sufficient information about what’s happening in your environment. We have researched selecting and deploying SIEM and Log Management extensively, and that information tends to be the low-hanging fruit for populating your internal security data repository. To aid investigation you should monitor the following sources (preferably continuously): Perimeter networks and devices: The bad guys tend to be out there, meaning they need to cross your perimeter to achieve their mission. So look for issues on devices between them and their targets. Identity: Who is as important as what, so analyze access to specific resources – especially within a privileged user context. Servers: We are big fans of anomaly detection, configuration assessment, and whitelisting on critical servers such as domain controllers and app servers, to alert you to funky stuff to investigate at the server level. Databases: Likewise, correlating database anomalies against other types of traffic (such as reconnaissance and network exfiltration) can indicate a breach in progress. Better to know that before your credit card brand notifies you. File integrity: Most attacks change key system files, so by

In the July 2 Incite I highlighted Dave Elfering’s discussion of the need to sell as part of your security program. Going through my Instapaper links I came across Dave’s post again, and I wanted to dig a bit deeper. Here is what I wrote in my snippet: Everyone sells. No matter what you do you are selling. In the CISO context you are selling your program and your leadership. As Dave says, “To truly lead and be effective people have to be sold on you; on what and who you are.” Truth. If your team (both upstream / senior management and downstream / security team) isn’t sold on you, you can’t deliver news they need to hear. And you’ll be delivering that news a lot – you are in security, right? That post just keeps getting better because it discusses the reality of leading. You need to know yourself. You need to be yourself. More wisdom: “Credentials and mad technical skills are great, but they’re not who you are. Titles are great, but they’re not who you are. Who you are is what you truly have to sell and the leader who instead relies on Machiavellian methods to self-serving ends is an empty suit.” If you can’t be authentic you can’t lead. Well said, Dave. Let’s dig a little deeper into the leadership angle here, because that’s not something most security folks have been trained to do. Here is another chunk of Dave’s post. As a leader you are guaranteed to be put into a continuous onslaught of events and situations, the circumstances of which are often beyond your control. What you do control is how you deal with them. This will be decided by who you are. People who rely on intimidation through authority or the manipulation of personality ethic may be effective up to a point, but in the melee of events those alone aren’t sufficient. Leading is a personal endeavor, which reflects who you are. If you are an intimidator don’t be surprised when your team consists of folks who (for whatever reason) accept being intimidated. But at some point fear and manipulation run out of gas. There is a time and a place for almost everything. There are situations where someone must take the organization on their back and carry it forward by whatever means necessary. That situation might be neither kind nor graceful. But it is also not sustainable. At some point your team needs to believe in its mission. They need to believe in their strategy for getting there. And they need to understand how they will improve and grow personally by participating. They need to want to be there, and to put forth the effort. Especially in security, given the sheer number of opportunities security folks have to choose from. Security is a hard path. You need to be tough to handle the lack of external validation, and the fact that security is not something you can ever win or finish. But that doesn’t mean you (as a leader) have to be hard all the time. At the end of the day we are all people, and we need to be treated that way. Photo credit: “LEAD” originally uploaded by Leo Reynolds Share:

Every time I took a new job, on my first day I would tell the team that I hate surprises. What I really meant was a warning, not to screw something up and not tell me. That’s not really a surprise, per se. More a failure to communicate. But now that I’m a bit older I realize the importance of surprises. When you are surprised it really means you had no expectations. For example, if I really didn’t like surprises I wouldn’t have appreciated the fact that The Boy took a hip-hop dancing elective at camp. That’s right, hip-hop dancing. That’s nothing less than shocking. He’s a pretty shy kid, and definitely doesn’t like to be the center of attention. Or so I thought. So hearing about him getting onstage to do a hip-hop routine was an awesome surprise. The flip side of a pleasant surprise is disappointing surprise. Of course we all feel disappointment at some point. It happens when you enter a situation and expectations are unmet. This all comes back to managing expectations. I know what you’re thinking – who cares? I do. I spent a long time disappointed with almost everything, because my expectations were unrealistic and usually unmet. I was constantly surprised because I expected things to happen, and I got bent out of shape when they didn’t. One of the things I’ve been working on is having no expectations – or at least very limited expectations. For example, if I’m about to go out for the evening with friends I expect to end up back at home, and not naked in a crackhouse without any money. See how easy that was? Having realistic expectations is pretty straightforward. And if you do find yourself in that situation, there’s probably a great story to be told… once you get out of rehab. All kidding aside, the sooner you can release most of your expectations, the sooner you will have more pleasant surprises and much less disappointment. –Mike Photo credit: “Surprise” originally uploaded by Tom Rolfe 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 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. 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 May 5 – There Is No SecDevOps April 28 – The Verizon DBIR April 14 – Three for Five March 24 – The End of Full Disclosure March 19 – An Irish Wake 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. Leveraging Threat Intelligence in Incident Response/Management Really Responding Faster Introduction Endpoint Security Management Buyer’s Guide (Update) Mobile Endpoint Security Management Trends in Data Centric Security Tools Introduction Use Cases Understanding Role-based Access Control Advanced Concepts Introduction NoSQL Security 2.0 Understanding NoSQL Platforms Introduction Newly Published Papers Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection Defending Against Network-based DDoS Attacks Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Eliminating Surprises with Security Assurance and Testing Incite 4 U Penetrating words about vulnerabilities: Daniel Miessler clarifies the distinctions between a vulnerability assessment and a penetration test. This is a good discussion – some organizations don’t know what they are buying when they select one or the other. Daniel offers a clean distinction: “The only key attributes of a VA vs. PT are list-orientation vs. goal-orientation…” A vulnerability assessment should produce a comprehensive list, while a penetration test has a mission to accomplish. But in the end the definitions aren’t even that important. The key is to know what you are buying. You likely need both, but if you expect a comprehensive list of issues from penetration testers you will be disappointed. – MR iPhone as a political pawn: As discussed in this week’s Firestarter, state-run China Central Television called out Apple’s iPhone as a national security concern because of fears that iOS “frequent location” data could leak and compromise state secrets. Apple responded succinctly yesterday: Apple does not have access to Frequent Locations or the location cache on any user’s iPhone at any time. Obviously the iPhone uses location data, and users can share geolocation data with individual apps as desired. We assume China Central Television’s coverage is politically motivated national posturing, laying out ground rules on surveillance and data collection. After all, the iPhone is made in China so it’s hard to imagine how much of a threat to national security it really is. The real issue is not being discussed: In response to legal demands from nation such as the USA and China for iPhone user location data, what will Apple provide (what has Apple provided) and who will be notified, if anyone. – AL Trees don’t grow to the sky: Just in case you thought any of these megacapitalized technology giants would grow to the stratosphere… forget it. It looks like the German government is looking to more heavily regulate the large web advertising businesses and treat them like utilities to make sure pricing doesn’t get out of hand. The Europeans in general are far more egalitarian than on

Many CISOs I have worked with over the past 10 years have consistently complained that no one else in the executive suite understands them. They can’t get the right level of support. They face constant roadblocks. Basically, they’re perplexed that business people are actually more worried about business. My response has always been that they weren’t Pragmatic enough. Of course they can read the book. Maybe they even adopt the concepts, and some will still run into the same difficulties. Basically, business folks won’t get it – until they have to. And lately, given the high-profile breaches and the beginning of CEO witch hunts, senior executives can no longer avoid security. Not entirely, anyway. But some CISOs have broken through and become real executives. Folks who other executives consult when making decisions. A person, running a group that adds value to the organization. I know! That’s pretty cool. How do you get there? Yes, you should be Pragmatic. But you can also take some tips from Qualys’ CSO, Andrew Wild. He gave a pretty good interview to the Enterprisers Project about how CISO can break through. Shockingly enough, it involves talking in business speak. “The board level interest requires a risk-based approach, and infosec leaders must embrace this and move away from a security controls focused approach to information security. That’s not to say that security controls aren’t important, because they are, but, from the top down, the focus needs to be on risk management. A critical component of implementing a successful risk-based approach is building strong relationships with business units, approaching them in a consultative manner to offer assistance and guidance.” — Andrew Wild, CSO, Qualys There are many other good tidbits in that interview. But remember that if you want to play in the C suite you had better understand your business and how security can make it better – whatever that means for you. Photo credit: “CEO – Tiare – Board Meeting – Franklin Canyon” originally uploaded by tiarescott   Share: