Research

I am still experimenting with posting research, from drafts through the editing process, on GitHub. No promises that we will keep doing this – it depends on the reaction we get. From a workflow standpoint it isn’t much more effort for us, but I like the radical transparency it enables. I just posted a second paper, which is still very much incomplete. I want to offer some instructions on how to edit or propose changes. This is just quick and dirty, and you should review the GitHub Help to really understand the process. GitHub is meant for code but works for any text files. Unlike any other option we found, GitHub offers an open, transparent way to not only collect feedback, but also to solicit and manage direct edits. Once you set it up the first time it is pretty easy – you subscribe, pull down a copy of the research, make your own edits, then send us a request to incorporate your changes into our master copy. Another nice feature is that GitHub tracks the entire editing process, including our internal edits. For transparency that’s sweet. I don’t expect many people to take advantage of this. I am currently the only Securosis Analyst doing it, and based on your feedback we will decide whether we should continue. Even if you don’t push changes or comments, let us know what you think. Here’s how: We will post all our research at https://github.com/Securosis. Right now I still need to move the Pragmatic Network Security Management project over there because I was still learning the process when I posted that one. For now you can find the research split between those two places. If you only want to leave a comment you can do so here on the blog post, or as an ‘Issue’ on GitHub. Blog comments can be anonymous but GitHub requires an account to create or edit an issue. Click ‘Issues’ and then simply add yours. If you want to actually make edits, go for it! To do this you need to both create a GitHub account and install the software. For you non-command-line types, you can download official GUI versions here. If you are running Linux git is probably already installed. If you try to use the git command under OS X 10.9 Mavericks, the system should install the software if necessary. Next, fork a copy of our repository. Go to https://github.com/Securosis, click the Fork button, and follow the instructions. That fork isn’t on your computer for editing yet, so synchronize your repository. This pulls down the key files to your system. On the web page click “Clone to Desktop”, it will launch your client, and you can choose where to save the fork. Edit away locally. This doesn’t affect our canonical version – just your fork of it. When you are done, commit your changes in your desktop GUI by clicking Changes, then Commit and Sync. Don’t forget to comment on your changes so we know why you submitted them. Then submit a pull request. This notifies us that you made changes. We will run through them and accept or decline. It is our research, after all. This is all new to us, so we need your feedback on whether it is worth continuing. We know many of you might be interested in tracking the research but not participating, and that’s fine, but if you don’t email or send us comments we won’t know you like it. Share:

It has been a while, but it is time to jump back into the Application Denial of Service series with both feet. As we described in the introduction, application denial of service can be harder to deal with than volume-based network DDoS because it is not always obvious what’s an attack and what’s legitimate traffic. Unless you are running all your traffic through a scrubbing center, your applications will remain targets for attacks that exploit the architecture, application stacks, business logic, and even legitimate functionality of the application. As we start digging into specific AppDoS tactics, we will start with attacks that target the server and infrastructure of your application. Given the popularity and proliferation of common application stacks, attackers can attack millions of sites with a standard technique, most of which have been in use for years. But not enough web sites have proper mitigations in place. Go figure. Server and infrastructure attacks are the low-hanging fruit of application denial of service, and will remain that so long as they continue to work. So let’s examine the various types of application infrastructure attacks and some basic mitigations to blunt them. Exploiting the Server Most attacks that directly exploit web servers capitalize on features of the underlying standards and/or protocols that run the web, such as HTTP. This makes many of these attacks very hard to detect because they look like legitimate requests – by the time you figure out it’s an attack your application is down. Here are a few representative attack types: Slowloris: This attack, originally built by Robert ‘RSnake’ Hansen, knocks down servers by slowly delivering request headers, forcing the web server to keep connections open, without ever completing the requests. This rapidly exhausts the server’s connection pool. Slow HTTP Post: Similar to Slowloris, Slow HTTP Post delivers the message body slowly. This serves the same purpose of exhausting resources on the web server. Both Slowloris and Slow HTTP Post are difficult to detect because their requests look legitimate – they just never complete. The R-U-Dead-Yet attack tool automates launching a Slow HTTP Post attack via an automated user interface. To make things easier (for your adversaries), RUDY is included in many penetration testing tool packages to make knocking down vulnerable web servers easy. Slow Read: Yet another variation of the Slowloris approach, Slow HTTP Read involves shrinking the response window on the client side. This forces the server to send data to the client slowly to stay within the response window. The server must keep connections open to ensure the data is sent, which means it can be quickly overwhelmed with connections. As with RUDY, these techniques are already weaponized and available for easy download and usage. You can expect innovative attackers to combine and automate these tactics into weapons of website destruction (as XerSeS has been portrayed). Regardless of packaging, these tactics are real and need to be defended against. Mitigating these server attacks typically requires a combination of web server configuration with network-based and application-based defenses. Keep in mind that ultimately you can’t really defend the application from these kinds of attacks because they are just taking advantage of web server protocols and architecture. But you can blunt their impact with appropriate controls. For example, Slowloris and Slow HTTP Post require tuning the web server to increase the maximum number of connections, prevent excessive connections from the same IP address, and allow a backlog of connection requests to be stored – to avoid losing legitimate application traffic. Network-based defenses on WAFs and IPSes can be tuned to look for certain web connection patterns and block offending traffic before the server becomes overwhelmed. The best approach is actually all of the above. Don’t just tune the web server or install network-based protection in front of the application – also build web applications to limit header and body sizes, and to close connections within a reasonable timeframe to ensure the connection pool is not exhausted. We will talk about building AppDoS protections into applications later in this series. An attack like Slow HTTP Read games the client side of the connection, requires similar mitigations. But instead of looking for ingress patterns of slow activity (on either the web server or other network devices), you need to look for this kind of activity on the egress side of the application. Likewise, fronting the web application with a CDN (content delivery network) service can alleviate some of these attacks, as your web application server is a step removed from the clients, and insulated from slow reads. For more information on these services, consult our Quick Wins with Website Protection Services paper. Brute Force Another tactic is to overwhelm the application server – not with network traffic, but by overloading application features. We will cover an aspect of this later, when we discuss search engine and shopping cart shenanigans. For now let’s look at more basic features of pretty much every website, such as SSL handshakes and serving common web pages like the login screen, password reset, and store locator. These attacks are so effective for overwhelming application servers because functions like SSL handshake and pages which require database calls are very compute intensive. Loading a static page is easy, but checking login credentials against the hashed database of passwords is a different animal. First let’s consider the challenges of scaling SSL. On some pages, such as the login page, you need to encrypt traffic to protect user credentials in motion. SSL is a requirement for such pages. So why is scaling SSL handshaking such an issue? As described succinctly by Microsoft in this Tech Bulletin, there are 9 distinct steps in establishing a SSL handshake, many of which require cryptographic and key generation operations. If an attacker uses a rented botnet to establish a million or so SSL sessions at the same time, guess what happens? It is not a bandwidth issue – it is a compute problem – and the application becomes unavailable because no more SSL

It was kind of a joke between two friends on a journey to become better people. Jen Minella (JJ) and I compared notes over way too many drinks at last year’s RSA, and we decided our experiences would make a good talk. I doubt either of us really thought it would be interesting to anyone but us. We were wrong. At RSA we will do a session called “Neuro-hacking 101: Taming Your Inner Curmudgeon”. Here is the description: For self-proclaimed security curmudgeons and anyone else searching for better work/life balance, this session is a how-to guide for happiness, health and finding a paths to increased productivity. Case studies, methods and research in the science of mind and body are followed up with resources and ways to get started. From neuroscience to nutrition, there’s something for everyone. JJ summed up her thoughts on the pitch, and I feel pretty much the same way. And so today, I’m overjoyed, a little relieved, excited at the opportunity, and yet at the same time a big piece of me is completely mortified. This talk, although founded in science, is a big lift of ol’ virtual skirt. It’s a talk about being happy, getting a grip on life, and using mindfulness to succeed and excel at everything you do. We do not pass go, we do not collect $200. Instead, we’re taking a nose dive into traditionally taboo topics and expose what many consider to be deportments of an intimate and personal nature. But we reached a mutual conclusion – how we think and communicate about the topics of mindfulness shouldn’t be secreted. There’s no shame in participating in activities (or inactivity) designed to make us better, happier, more productive people. I don’t wear a virtual skirt, but it is a bit scary to provide a view into the inner workings of my improvement processes to be less grumpy and more content with all I have achieved. I’ve talked about some of those topics in past Incites, but never to this degree. And that’s good. No, it’s great. Hope to see you there. Share:

  Before I dive into this week’s sermon, just a quick note that our posting will be a bit off through the end of the year. As happens from time to time, our collective workloads and travel are hitting insanity levels, which impedes our ability to push out more consistent updates. But, you know, gotta feed the kids and dogs. A couple weeks ago I got to abandon my family during the weekend and spend my time in a classroom renewing my Emergency Medical Technician certification. I was close to letting it go, but my wife made it abundantly clear that she would rather lose me for a weekend than deal with the subsequent years of whining. I never look forward to my recert classes. It is usually 2-3 days in a classroom, followed by a written and psychomotor (practical) test. I first certified as an EMT in 1991, and then became a paramedic in 1993 (which is an insane amount of training – no comparison). I won’t say I don’t learn anything in the every-two-year refresher classes, but I have been doing this for a very long time. But this year I learned more than expected, and some of it relates directly to my current work in security. Five or six years ago I started hearing about some new trends in CPR. A doctor here in Phoenix started a research study to try a completely nonconventional approach to CPR. The short version is that the human body, when dead, isn’t using a ton of oxygen. Even when alive we inhale air with 21% O2 and exhale air with 16% O2. Stop all muscular activity and the brain will mostly suck out whatever O2 is circulated when you compress someone’s chest. This doc had some local fire departments use hands-only CPR and 300 compressions with no ventilations. This keeps the blood pressure up and blood circulating, and the action of pushing the chest generates more than enough air exchange. The results? Something like 3x the survival rates. The CPR you learn today probably isn’t there yet, but definitely emphasizes compressions more than mouth-to-mouth, which I suspect will be dropped completely for adults if the research holds. There’s more to it, but you get the idea. All right, interesting enough, but what does this have to do with security? I found myself instinctively clinging to my old concepts of the ‘right’ way to do CPR despite clear evidence to the contrary. I understand the research, and immediately adopted the changes, but something felt wrong to me. I have been certified in what are basically the same essential techniques for nearly 30 years. Part of me didn’t want to let go, and that wasn’t a feeling I expected. I later had the same reaction to changes in the treatment of certain closed head injuries, but that more due to specific cases where I used techniques now known to harm patients. I am an evidence-based guy. I roll with the times and try not to cling to convention, but somewhere in me, especially as I get older, part of the brain reacts negatively to changing old habits. Fortunately, my higher-order functions know to tell that part to shut the hell up. We have a tendency to imprint on whatever we first learn as ‘correct’. Perhaps it was the act of discovery, or forming those brain pathways. In security we see this all the time. I once had an IT director tell me he would rather allow Windows XP on his network over iPads, because “we know XP”. Wrong answer. The rate of change in security exceeds that of nearly every other profession. Even developers can often cling to old languages and constructs, and that profession is probably the closest. I like to think of myself as an enlightened guy capable of assimilating the latest and greatest within the context of what’s known to work, and I still found myself clinging to a convention after it was scientifically proven wrong. I don’t think any of us are in a position to blame others for “not getting it”. All of us are luddards – you just need to hunt for the right frame of reference. That is not an excuse, but it is life. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Nada. Unless Google and Bing are both lying to me. Like I said, busy week. Favorite Securosis Posts Adrian Lane: Microsoft Upends the Bug Bounty Game. This may work. Mike Rothman: Microsoft Upends the Bug Bounty Game. Not a lot of choice this week (yes, I have been the suck at blogging lately). But Rich does a nice job explaining the ripple effects of Microsoft extending their bounty program. Rich: New Series: The Executive Guide to Pragmatic Network Security Management. The post isn’t new, but I can announce that RedSeal Networks intends to license it (pending the end of our open peer review process). And don’t forget that this is the first papare we are opening up for full public change tracking on GitHub. Other Securosis Posts Friday Summary: Halloween 2013 Edition. Favorite Outside Posts Adrian Lane: I Love the Smell of Popcorn in the Morning. Why did I choose to never be a CIO again? This is why. You’d think this type of story would be rare, but it’s common. However, it only occurs at 2:00am or on your first day of vacation. Mike Rothman: Five Styles of Advanced Threat Defense. The Big G does a decent job of explaining the overlap (and synergy) of these so-called Advanced Threat product categories. I differ slightly on how to carve things up but this is close enough for me to mention. Rich: IT Security from the Eyes of Data Scientists. Yep, serious job security if you head down this path. Research Reports and Presentations Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Dealing with

  Microsoft is expanding its $100k bounty program to include incident responders who find and document Windows platform mitigation flaws. Today’s news means we are going from accepting entries from only a handful of individuals capable of inventing new mitigation bypass techniques on their own, to potentially thousands of individuals or organizations who find attacks in the wild. Now, both finders and discoverers can turn in new techniques for $100,000. Our platform-wide defenses, or mitigations, are a kind of shield that protects the entire operating system and all the applications running on it. Individual bugs are like arrows. The stronger the shield, the less likely any individual bug or arrow can get through. Learning about “ways around the shield,” or new mitigation bypass techniques, is much more valuable than learning about individual bugs because insight into exploit techniques can help us defend against entire classes of attack as opposed to a single bug – hence, we are willing to pay $100,000 for these rare new techniques. This is important because Microsoft just turned every target and victim into a potential bug hunter. The pool of people looking for these just increased massively. Previously only security researchers could hunt these down and win the cash. Researchers can be motivated to sell bugs to governments or criminals for more then $100k (Windows mitigation exploits are extremely valuable). Some professional response teams like to keep exploit details and indicators of compromise trade secrets, but not every response team is motivated that way. This alters the economics for attackers, because they now need to be much more cautious in using their most valuable 0day exploits. If they attack the wrong target they are more likely to lose their exploit forever. As exciting as this is, it still requires a knowledgeable defender who isn’t financially motivated to keep it secret (again, some vendors and commercial IR services). And there are plenty of lower-level attacks that still work. But even with those stipulations the pool of hunters just increased tremendously. Share:

  While you’re thinking about little kids in scary costumes, I’m here thinking about adults who write scary code. As I go through the results of a couple different companies’ code scans I am trying to contrast good vs. bad secure development programs. But I figure I should ask the community at large: What facet of your secure software development program has been most effective? Can you pinpoint one? For many years I felt placing requirements within the development lifecycle (i.e.: process modifications) yielded the greatest returns. I have spoken with many development teams over the past year who said that security awareness training was the biggest benefit, while others most appreciated threat modeling. Still others claimed that external penetration testing or code scans motivated their teams to do better, learn more about software defects, and improve internally. The funny bit is that every team states one of these events was the root cause which raised awareness and motivated changes. Multiple different causes for the same basic effect. I have been privy to the results from a few different code scans at different companies this summer; some with horrific results, and one far better than I could have ever expected, given the age and size of the code base. And it seems the better the results, the harder the development team takes external discoveries of security defects. Developers are proud, and if security is something they pride themselves on, defect reports are akin to calling their children ugly. I am typically less interested in defect reports than in understanding the security program in general. Part of my interest in going through each firm’s secure development program is seeing what changes were made, and which the team found most beneficial. Once again, the key overall benefit reported by each team varies between organizations. Many say security training, but training does not equal development success. Others say “It’s part of our culture”, which is a rather meaningless response, but those organizations do a bit of everything, and they scored considerably better on security tests. It is now clear to me, despite my biases for threat modeling and process changes, that for organizations that have been doing this a while no single element or program that makes the difference. It is the cumulative effect of consistently making security part of code development. Some event started the journey, and – as with any skill – time and effort produced improvement. But overall, improvement in secure code development looks glacial. It is a bit like compound interest: what appears minuscule in the beginning becomes huge after a few years. When you meet up with organizations that have been at it for a long time, it is startling see just how well the basic changes work. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Dave Lewis’s CSO post: “LinkedIn intro: Data, meet security issues”. Juniper blog quotes Adrian on DB-DoS. Adrian’s DR post: Simple is better. Gunner on The Internet-of-Things. Favorite Securosis Posts David Mortman: Don’t Mess with Pen Test(ers). Adrian Lane: Thinking Small and Not Leading. It is unfortunately common to discover that a job is quite different than you thought. And how best to accomplish your goals often involves several rounds of trial and error. Mike Rothman: The Pragmatic Guide to Network Security Management: The Process. Rich had me at Pragmatic… Other Securosis Posts The Pragmatic Guide to Network Security Management: SecOps. Incite 10/30/2013: Managing the Details. New Series: The Executive Guide to Pragmatic Network Security Management. Summary: Planned Coincidence. Favorite Outside Posts Dave Lewis: Buffer Hacked. David Mortman: Adventures in Dockerland. Not a security article but something for security to keep in mind. Docker is making big inroads in the cloud, especially PaaS, so you need to understand it. Adrian Lane: Big Data Analytics: Starting Small. A short post with pragmatic advice. Mike Rothman: Time doesn’t exist until we invent it. As always, interesting perspective from Seth Godin about time… “Ticking away, the moments that make up a dull day…” Gal: Fake social media ID duped security-aware IT guys. Research Reports and Presentations Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Dealing with Database Denial of Service. The 2014 Endpoint Security Buyer’s Guide. The CISO’s Guide to Advanced Attackers. Defending Cloud Data with Infrastructure Encryption. Network-based Malware Detection 2.0: Assessing Scale, Accuracy and Deployment. Top News and Posts Kristin Calhoun Keynote at API Strategy and Practice WhiteHat has a new secure browser; what does the Firefox say? via Wendy Nather. A More Agile Healthcare.gov NSA Chief: ‘To My Knowledge’ Agency Didn’t Tap Google, Yahoo Data Centers Mozilla Shines A Light With Lightbeam Alleged Hacker V& In DOE, HHS Breaches MongoHQ Suffers Security Breach Blog Comment of the Week This week’s best comment goes to Zac, in response to Don’t Mess with Pen Test(ers). As you say, we try not to focus on or fixate on the potential risks. There are however ways to mitigate or reduce the risk. Foremost for me is to consider any and all electronic transactions to be accessible and therefore never put anything I want to keep private out of electronic records. Just like how in the past you wouldn’t speak of things you wanted to keep private today you don’t post it (Facebook is training people to do all the wrong things). And when you consider that medical offices, tax agencies, government agencies, companies all either experience breaches or just plain send your informaiton to the wrong people… let alone work at getting your informaiton. Or how snail mail post can end up in the wrong mailbox… One may as well stay home due to a fear of being hit by a car while walking the dog. tl;dr – if you want to keep something private… keep it to yourself. Share:

  This is part 3 in a series. Click here for part 1, or submit edits directly via GitHub. Workflows: from Sec and Ops to SecOps Even mature organizations occasionally struggle to keep security aligned with infrastructure. But low-friction processes that don’t overly burden other areas of the enterprise reduce both errors and deliberate circumvention. Frequently the problem manifests as a lack of communication between network security and network operations. Not out of antagonism but simply due to different priorities, toolsets, and issues to manage on a day to day basis. A seemingly minor routing change, or the addition of a new server, can quietly expose the organization to new risks if security defenses aren’t coordinated. On the other hand, security can easily break things and create an operational incident with a single firewall rule change. Efficient programs don’t just divide up operational responsibilities – they implement workflows where each team does what they are best at, while still communicating cleanly and effectively to each other. Here are examples of four integrated operations workflows: Network topology changes: Changes to the topology of the network have a dramatic impact on the configuration of security tools. The workflow consists of two tracks – approved changes and detected changes. For approved changes the network team defines the change and submits it to security for review. Security analyzes it for impact, including any risk changes and required security updates. Security then approves the change for operations to implement. Some organizations even have network operations manage basic security changes – mostly firewall rule updates. A detected change goes through the same analysis process but may require an emergency fix or communications with the network team to roll back the change (and obviously requires ongoing monitoring for detection in the first place). In both cases it can be helpful to integrate the process into your change management or workflow tool to automatically route tasks. Business exemption or change requests: Occasionally a business unit will need a change to network security. Many of these come through network operations, but quite a few come from application teams or business units themselves for particular projects. The same basic process is followed – the change request comes in, is analyzed for risks and required changes, and then approved, implemented, and validated. As before, you also should plan to monitor for and manage unapproved changes, which is where application-aware monitoring is particularly helpful. Also, consider making a portal for business units to submit and track requests, rather than handling through email or spreadsheets. New assets and applications: Similar to a business exemption or change request, but focused on new projects and assets rather than creating a special exemption to existing policy. There may be more planning, earlier in the process, with a lot more people involved. Develop a two-track process – one for new applications or assets that are fairly standard (e.g., a business unit file server or basic web application) which can be more automated, and a second for larger programs such as major new applications. New security tools or policy changes: Adding a new security tool or policy change reverses the workflow, so the responsibility is now on the security team to initiate communications with network operations and other affected teams. Security should first analyze the change and potential downstream impacts, then work with teams to determine operational risks, timelines, and any other requirements. Conclusion Network security management isn’t easy, but there are more and less efficient ways to handle it. Knowing your posture and maintaining visibility are key, as are developing core workflows to bridge gaps between different operational teams. Network security operations monitors the environment and change requests to adapt the security posture as needed in a timely manner. It monitors for changes that slip through outside approved processes, develops workflows to handle the unexpected, and responds quickly when changes are requested to support other business areas. Finally, network security understands that security policy changes impact other operations, along with the need to analyze and communicate these potential implications. It is not always easy, but it is far more efficient and effective than the alternatives, and frees up the security team to focus on what they are best at. Share:

Almost everyone you know is blissfully unaware of the digital footprints we all leave, and how that information can be used against us. The problem is that you understand, and if you spent much time thinking about it you’d probably lose your mind. So as a coping mechanism you choose not to think of how you could be attacked or how your finances could be wrecked, if targeted by the wrong person. Just in case you didn’t have enough to worry about today, you can check out this great first-person account of a personal pen test on Pando Daily. A NYU professor challenged the folks at Spider Labs to take a week and find out what they could about him. It wasn’t pretty. But then again, you knew that’s how the story would end. What I learned is that virtually all of us are vulnerable to electronic eavesdropping and are easy hack targets. Most of us have adopted the credo “security by obscurity,” but all it takes is a person or persons with enough patience and know-how to pierce anyone’s privacy – and, if they choose, to wreak havoc on your finances and destroy your reputation. The story details the team’s attempts to gain presence on his network and then devices. They finally went through the path of least resistance: his wife. The tactics weren’t overly sophisticated. But once armed with some basic information it was game over. The pen testers gained access to his bank accounts, brokerage information, phone records, and the like. What do we accomplish by reminding ourselves of the risks of today’s online life? Nothing. You know the risks. You take the risks. The benefits outweigh the risks. And now I’ll crawl back into my fog to become once again blissfully unaware. Share:

  As I wrote a few weeks ago, everyone has their strengths. I know that managing the details is not one of mine. In fact I can’t stand it, which is very clear as we prepare for our oldest daughter’s Bat Mitzvah this weekend. It’s a right of passage signaling the beginning of adulthood. I actually view it as the beginning of the transformation to adulthood, which is a good way to look at it because many folks never complete that transition – at least judging from the way they behave. Coming back to the topic at hand, the sheer number of details to manage between the Friday night dinner, refreshments after the Friday service, the luncheon after the Saturday ceremony, the big party we’re throwing Saturday night, and the brunch on Sunday, are crazy. The Boss has mostly done nothing besides manage all those details for the past 6 months, and was immersed in the process for the year before that. I am thankful she shielded me from having to do much, besides lug some things from place to place and write a few (okay – a lot) of checks. We have many great friends who have helped out, and without them we would have been sunk. So many things have to be decided that you don’t even think about. Take lighting, for instance. Who cares about the lights? No one, unless the place is either too dark or too light. The proximity of the tables to the speakers? Yup, that needs to be managed because some folks have sensitive ears and can’t be too close to the dance floor. Who knew? The color of the tablecloths is important – it needs to match the seat covers and napkins. The one detail I did get involved in was the liquor. You can bet I was going to have a say in what kind of booze we had for the party. That’s a detail I can get my arms around. And I did. There will be Guinness. And it will be good. When we first went through the plans and the budget I was resistant. It’s hard to fathom spending the GNP of a small nation in one night. But as we get closer, I’m glad we are making a huge event. It’s very very rare that we get together with most of the people we care about to celebrate such a happy occasion. I can (and will) make more money, but I don’t know how many more opportunities I’ll have to share such happiness with my parents and in-laws. So I will enjoy this weekend. I’m not going to think about what it costs or how many webcasts I had to do to pay for it. I will be thankful that we are in a position where we can throw a big party to celebrate the fact that XX1 is growing up. I am going to appreciate all the work she put in to get ready to lead the services on Friday and Saturday. She has probably put in another 10-15 hours a week in preparation, on top of her schoolwork and rigorous dance schedule. She hasn’t slept much the past few weeks. It’s important that I savor the experience. I have been bad at that in the past. I will talk to all the people who traveled great distances to celebrate with us, and who I don’t get to see often. I’m going to smile. A lot. And lastly, I will follow Alan Shimel’s advice to not get so drunk I need to watch the video to remember what happened at the party. That’s probably the best piece of advice anyone could have given me. You don’t get many chances to see your baby girl in the spotlight. You might as well remember it. –Mike Photo credit: “Whiteboard of the now: The To-Do list” originally uploaded by Jenica Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Security Awareness Training Evolution Quick Wins Focus on Great Content Why Bother? Executive Guide to Network Security Management New Series: The Executive Guide to Pragmatic Network Security Management Defending Against Application Denial of Service Introduction Newly Published Papers Firewall Management Essentials Continuous Security Monitoring API Gateways Threat Intelligence for Ecosystem Risk Management Dealing with Database Denial of Service Identity and Access Management for Cloud Services The 2014 Endpoint Security Buyer’s Guide The CISO’s Guide to Advanced Attackers Incite 4 U Stories make the point: Any effective communicator is a storyteller. People understand stories. Folks can find applicability to whatever situation they are in through a carefully crafted fable or analogy. When trying to create urgency for something as obscure as a malware attack (It does what? Why do I care about that?), it helps to have a way to relate it to non-security folks. The Analogies Project is a new initiative aiming to assemble a library of analogies about security that anyone can use to make specific points. I haven’t read them all, but a few were pretty good. Those of us in the business for a long time, and who communicate for a living, have a ton of stories from our travels through over years. But for those of you who don’t, there is bound to be an analogy that will resonate with the person you are trying to persuade. Check it out. – MR Who are you? Adrian and I have both been talking about different aspects of identity management in the cloud lately. Why should you care? Because if you don’t adopt some sort of federated identity option your life will be a screaming poopstorm of pain until the end of time. No, I’m not exaggerating. I can barely manage a dozen employee accounts on

  This is part 2 in a series. Click here for part 1, or submit edits directly via GitHub. The Pragmatic Process As mentioned in the previous section, this process is designed primarily for more complex networks, and takes into account real-life organizational and technological complexities. Here is the outline, followed by the details: Know your network. Know your assets. Know your security. Map the topology. Prioritize and fix. Monitor continuously. Manage change and build workflows. The first five steps establish the baseline, and the next two manage the program, although you will need to periodically revisit previous steps to ensure your program stays up to date as the business evolves and risks change. Know Your Network You can’t secure what you don’t know, but effectively mapping a network topology – especially for a large network – can be daunting. Many organizations believe they have accurate network topologies, but they are rarely correct or complete – for all the reasons in the previous section. The most common problem is simply failure to keep up-to-date. Topology maps are produced occasionally as needed for audits or projects, but rarely maintained. The first step is to work with Network Operations to see what they have and how current it is. Aside from being politically correct, there is also no reason not to leverage what is already available. Position it as “We need to make sure we have our security in the right places,” rather than “We don’t trust you.” Once you get their data, evaluate it and decide how much you need to validate or extend it. There are a few ways to validate your network topology, and you should rely on automation when possible. Even if your network operations team provides a map or CMDB, you need to verify that it is current and accurate. One issue we see at times is that security uses a different toolset than network operations. Security scanners use a variety of techniques to probe the network and discover its structure, but standard security scanners (including vulnerability assessment tools) aren’t necessarily well suited to building out a complete network map. Network operations teams have their own mapping tools, some of which use similar scanning techniques, but add in routing and other analyses that rely on management-level access to the routers and network infrastructure. These tools tend to rely more on trusting the information provided to them and don’t probe as heavily as security tools. They also aren’t generally run organization-wide on a continuous basis, but are instead used as needed for problem-solving and planning. Know Your Assets Once you have a picture of the network you start evaluating the assets on it: servers, endpoints, and other hardware. Security tends to have better tools and experiences for scanning and analyzing assets than underlying network structure, especially for workstations. Depending on how mature you are at this point, either prioritize your scanning to particular network segments or use the information from the network map to target weak spots in your analysis. Endpoint tools such as configuration/patch management or endpoint protection platforms offer some information, but you also need to integrate a security scan (perhaps a vulnerability assessment) to identify problems. As before, this really needs to be a continuous process using automated tools. You also need a sense of the importance of the assets, especially in data centers, so you can prioritize defenses. This is a tough one, so make your best guesses if you have to – it doesn’t need to be perfect. Know Your Security You need to collect detailed information on three major pieces of network security: Base infrastructure security. This includes standard perimeter security, and anything you have deployed internally to enforce any kind of compartmentalization or detection. Think firewalls (including NGFW), intrusion detection, intrusion prevention, network forensics, Netflow feeds to your SIEM, and similar. Things designed primarily to protect the core network layer. Even network access control, for both of you using it. Extended security tools. These are designed to protect particular applications and activities, such as your secure mail gateway, web filter, web application firewalls, DLP, and other “layer 7” tools. Remote access. Security tends to be tightly integrated into VPNs and other remote access gateways. These aren’t always managed by security, but unlike network routers they have internal security settings that affect network access. For each component collect location and configuration. You don’t need all the deep particulars of a WAF or DLP (beyond what they are positioned to protect), but you certainly need complete details of base infrastructure tools. Yes, that means every firewall rule. Also determine how you manage and maintain each of those tools. Who is responsible? How do they manage it? What are the policies? Map the Topology This is the key step where you align your network topology, assets (focusing on bulk and critical analysis, not every single workstation), and existing security controls. There are two kinds of analysis to then perform: A management analysis to determine who manages all the security and network assets, and how. Who keeps firewall X up and running? How? Using which tool? Who manages the network hardware that controls the routing that firewall X is responsible for? Do you feed netflow data from this segment to the SIEM? IDS alerts? The objective is to understand the technical underpinnings of your network security management, and the meatspace mapping for who is responsible. A controls analysis to ensure the right tools are in the right places with the right configurations. Again, you probably want to prioritize this by assets. Do you use application-aware firewalls (NGFW) where you need them? Are firewalls configured correctly for the underlying network topology? Do you segment internal networks? Capture network traffic for detecting attacks in the right places? Are there network segments or locations that lack security controls because you didn’t know about them? Is that database really safe behind a firewall, is or it totally unprotected if a user clicks the wrong link in a phishing email?