Research

The methods by which applications and supporting infrastructure are developed and deployed are undergoing fundamental change. Avoiding the predictable hyperbole, new methods including DevOps and Cloud Computing promise to disrupt most of IT over the next 5-10 years. But embedded infrastructure and legacy applications are not going away. IT professionals need to walk a fine line between delivering critical services at the lowest price for acceptable performance, and doing it quickly and reliably. As usual, security is at the end of the tail being wagged. It’s hard enough to get developers to run a security scan on their code before it’s deployed into production. The idea of integrating security into these integrated development and operational processes (something Rich calls ‘SecOps’) seems like a pipe dream. It may be a dream today, but it needs to become reality sooner rather than later. IT has little choice. Adversaries continue to innovate and improve their tactics at an unprecedented rate. They have clear missions, typically involving exfiltrating critical information or impacting the availability of your technology resources. They have the patience and resources to achieve their missions by any means necessary. And it’s your job to make sure deployment of new IT resources doesn’t introduce unnecessary risk. With this need to move faster and to have more agile infrastructure, it is increasingly difficult to ensure proper testing for infrastructure and applications before they go live. You have all heard the excuses that emerge when something goes wrong with a deployment. We didn’t hit it with that much traffic. We didn’t get around to testing those edge cases. The application wasn’t designed to do that. Ho hum. Just another day in the office, and it’s security’s problem when the new application is compromised, data is lost, or the application falls over under the onslaught of a denial of service attack. It doesn’t need to be this way. Really – it doesn’t. Although in light of common experience, many security folks don’t believe this. The root cause of these issues is surprise. That’s right – when an application goes live (or a major change goes into production), you don’t really know what is about to happen, do you? You haven’t been through a rigorous process to ensure the application (and its infrastructure) is ready for prime time. And calling the application ‘Beta’ won’t save you. If the application has access to critical (regulated) information and is accessible – whether internally or externally – a security mindset is required, along with a way to put the application through its paces. As I wrote in the Pragmatic CSO, Basically you are trying to eliminate surprises. So by doing a full battery of tests before the new system is deployed, you reduce the likelihood that you are missing something that you’ll learn about later – the hard way. Technological disruption is not about to stop. If anything it will accelerate, so we need to get over our idea of a discrete security function maybe doing some testing and/or risk assessment at the tail end of a project. So what can and should security folks do? And how can they get both the development and operations teams on board with the necessary changes to ensure the protection and survivability of the application? To prevent surprise we suggest a security assurance and testing process for ensuring the environment is ready to cope with real traffic and real attacks. This goes well beyond what development organizations typically do to ‘test’ their applications, or ops does to ‘test’ their stacks. It also is different than a risk assessment or a manual pen test. Those “point in time” assessments look at what can happen but aren’t necessarily comprehensive. The testers may find a bunch of issues but not all the issues. So remediation decisions are made with incomplete information about the true attack surface of infrastructure and applications. So that is the topic of our next blog series, titled Eliminating Surprises with Security Assurance and Testing. We will dig into this process, discussing which devices and infrastructure components to test and how to consistently and reliable ensure you are testing the key functions. We will also focus on assuring the readiness and resilience of applications because they are often the path of least resistance for attacks. We would like to thank Ixia for agreeing to potentially license this content at the end of blog series. We will be developing it objectively, using our Totally Transparent Research methodology. We can provide this research to you at this most excellent price because our clients support our unconventional research model. Remember – your adversaries don’t need to hit an arbitrary deadline. They will take the time needed to find the chinks in your armor. Maybe it’s within the application, maybe it’s within the computing stack, maybe it’s the underlying equipment that gets data from one place to another. You can’t eliminate all the defects and security holes in your environment. But you can find out what they are and put a plan together to protect your environment. Deploying a security assurance and testing process to do just that is what this new series is all about. Share:

My friend Shimmy must have taken his nostalgia pills over the long weekend – on Monday he tweeted: Doesn’t it suck getting older I didn’t realize how truly carefree life was All is good here thinking about some new stuff Besides the fact that it’s Twitter-english (half sentences/thoughts to fit into 140 characters, punctuation not required), I disagree with that sentiment. I don’t think it sucks getting older. Aging is awesome. I’m not sure I would recognize my 24-year old self if I ran into him on the street. If I take a rare moment to reflect, almost every aspect of my life is better now. My main gripe is that my body is 20 years older, so my knees ache from time to time and it takes me a bit longer to kick a hangover. But on the list of potential issues, those are pretty minor. There is nothing saying that a carefree life is a better life. Or maybe I just never had a carefree life. When I was younger I was always striving. I had a timetable for success and wanted to hit my dates. A few years ago I dropped the timetable. I could do that because I changed my view of success, which is still evolving as I learn more about myself and what I’m really about. To be fair, there are Saturdays I would like to stay in bed until 2pm like I did 20 years ago. And there was something liberating about fitting pretty much all my possessions into a duffle bag or two. I had nothing to lose. But I don’t buy into the notion that having responsibilities (family, kids, expenses) is worse. In fact all I could think about when I had no responsibilities was my timetable to gain them. I searched for a partner and found the Boss. I worked hard at a number of jobs and then stumbled into research. Same old story. Lots of folks think the grass was greener in the past. Or will be greener in the future. They would rather be anywhere else but here. Any other time but now. Which is a shame. All we have is right now. The past is gone. The future hasn’t happened yet. What I want to do is enjoy the time I have, as long as it lasts. To age gracefully like a good single malt (and I don’t even like scotch). To leverage my experience and help people improve. To connect those I value to resources or knowledge I can access. Just thinking about it gets me fired up about the road ahead. But I shouldn’t beat Shimmy up too badly – he got it right in the last part of his tweet. All is good here. It sure is, brother. I wouldn’t trade my experiences, which have been a critical part of the journey. As I said in Live Right Now: “You could choose to live in the past. We need to be respectful of history, and learn the lessons of those that came before us.” I also said, “Think to the future not in fear and worry, but in hope and grace.” I’m choosing to live right now because I am finally old enough to appreciate the challenges of the alternatives. As Steve Jobs would say, this approach allows you to “Stay Hungry. Stay Foolish.” Which seems pretty carefree to me… –Mike Photo credit: “The Maltman Bowmore 21 Years” originally uploaded by Sven Cipido 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. What CISOs Need to Know about Cloud Computing Adapting Security for Cloud Computing How the Cloud is Different for Security Introduction Defending Against Application Denial of Service Building Protections In Abusing Application Logic Attacking the Application Stack Newly Published Papers Security Awareness Training Evolution 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 Staying focused on the prize: Our pal Wendy posted another terrific rant before the holiday. This time on user feedback in applications. In What’s my name? No, really, what is it?, she talks about how pen testers always gave her a hard time about the feedback given by the login process. With that information, the attacker could infer user IDs, etc. Wendy points out that is by design – if users cannot remember their user names they call the help desk. When they call the help desk it costs money or takes folks away from more important tasks. So yes, you need to balance the obscurity required to make it harder on attackers against the downside of making it harder for legitimate users. Which do you choose? Thought so. She closes with: “If your system can’t withstand attacks by someone who knows a valid username or email address, then you have MUCH bigger problems to solve.” Wendy drops the mic and goes home. – MR Super-unrelated: The PCI DSS 3.0 requirement that firms map the flow of payment card data is really nothing new – identifying what systems contain cardholder data has been part of every DSS specification since the beginning. Mapping the data flow and showing which users and applications have access to that data simply provides a clearer picture of how that data is used so you understand how best to safeguard it. For threat modeling this type of diagram is a must! The key is that it makes the assessor’s job easier to have a map of the systems in scope and subject to review. That does not address the flaw Troy Leach identifies: unknown and unsecured cardholder storage locations