Research

  Adrian put up an insightful (as opposed to inciteful) column on Dark Reading, pointing out that that Simple Security Is A Better Bet. Though I quibble a bit with the subhead: “Complex security programs are little better than no security”. Of course any subhead taken out of context creates opportunity for misinterpretation. I would reword to say, “Complex security programs done poorly are little better than no security”. But that’s just me. The fact is that any set of security controls chosen needs to be achievable by the organization. Even if that means attack surface remains unaddressed. What choice do you have? Even if it’s the low bar that most compliance mandates prescribe. Adrian does make that point effectively. …it was going to address most of the issues the company had – it was not even fully aware of the issues it needed to address – and it was within its capability to implement. I hate to do this because sometimes it feels like compliance for the sake of compliance. Obviously that’s suboptimal. Just like anyone else, I like to actually solve the problem, rather than just putting band-aid after band-aid on the wound. But pragmatism needs to win the day. Any organization pushing beyond its capabilities (and budget) will have problems because it won’t be able to execute – even worse, it might get a false sense of security. Photo credit: “failure-to-comply” originally uploaded by Brendan Riley Share:

As I mentioned a few weeks ago, XX1 had her Bat Mitzvah recently. It was great to be surrounded for a weekend by almost all the people we care about. And XX1 really stepped up and made us very proud. There are few things more gratifying than seeing your child excel – especially on a big stage in front of a lot of people. Part of the ceremony is a blessing from the parents. Some parents provide an actual blessing. Others tell entertaining stories about the child. I chose to give her some life perspective by distilling what I have learned over the past four decades down into a fairly simple concept. I understand she probably won’t get it for a while, but I’m okay with that. So here goes: I have no doubt you will move with grace to adulthood. In preparation for that transformation, let me share with you what I’ve discovered over the past 45 years. In fact, I believe it’s the secret to life. The secret to life? Wow. I know, it seems kind of deep. So here goes. The secret to life is to LIVE RIGHT NOW. I know it seems kind of underwhelming, but hear me out. Once I explain it a bit, maybe LIVE RIGHT NOW will make sense. You can choose to live in the future. Chasing dreams and aspirations and goals and life plans. You are so busy striving for what you don’t have, you never get around to appreciating what you do have. You’ll need to trust me on that. That doesn’t mean you can’t think to the future… but think to the future not in fear and worry, but in hope and grace. Realize you make the vision of your life a reality based on how you 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. But don’t be limited by the past. Learn from your own experiences, especially the challenging ones – then let them go. You have the power to create your own future. A future where you can achieve whatever you set your mind to and become absolutely anything you choose. Never forget that who you ARE doesn’t depend on who you WERE. You can and should be reinventing yourself as you move through life. Don’t let anything or anyone define you. Let your actions right now, in this moment, represent who you are and who you will become. Steve Jobs said it much more elegantly in his awesome Stanford Commencement address, “Your time is limited, so don’t waste it living someone else’s life. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become.” Understanding this secret doesn’t make it easy. Being yourself, loving yourself, and surrounding yourself with people who appreciate and love YOU for who YOU ARE is very difficult. You’ll face many challenges, make countless tough decisions and you’ll screw things up. That’s all part of this game we call life. Just be true to yourself and everything will be OK. I promise. Always remember your Mom and I will be there to support you – celebrating your accomplishments and helping you rebound from your setbacks. Most of all know that we love you, unconditionally and without bounds. I wanted to finish the speech with a Seinfeld quote, but “NO SOUP FOR YOU!” didn’t seem to fit. Instead I chose a passage from Seinfeld’s book that my father sent to me many years ago when I lost sight of what was important. “Life is truly a ride. We’re all strapped in and no one can stop it. As you make each passage from youth to adulthood to maturity, sometimes you put your arms up and scream, sometimes you just hang on to that bar in front of you. But the ride is the thing. I think the most you can hope for at the end of life is that your hair’s messed, you’re out of breath, and you didn’t throw up.” Strap in girlfriend, it’s a wild ride. –Mike 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 Sustainable security change: As we come up to the end of the year, countless folks will fall again into the trap of New Year’s resolutions. Something they are going to change for perhaps a few days in January, then it’s right back to the same old habits. Dave Elfering (whose blog is good – you should read it) talks a bit about Leading vs. Managing in the context of creating change. The process he references (from some work by John Kotter), involves the hard work of lining up support, creating a vision, communicating that vision, empowering action, generating short term wins, and consistency of enforcement to ensure the change sticks. This is hard stuff because everyone is constantly dealing with other shiny objects diverting their attention. Dave’s point is that managers can get things done. But it takes a leader to drive lasting change. I think he’s right. – MR Perverse security

  Given our severe skills gap in security, managed services and other security outsourcing tactics continue to be very interesting to end users. Either that, or non-security senior management gets frustrated by the inability of the internal team to get anything done, so they look at having someone else take a crack. As the NSS folks ask in their blog post, To Outsource or Not to Outsource, That is the Question!, but I don’t think that’s the right question. It’s really more about what they can outsource, not whether to outsource at all. Although their first sentence does irk me: Is it a good thing that one of the fastest growing segments in the field of information security revolves around surrendering control of your security to another party? Surrendering control? Really? That kind of attitude will get you killed. If there is one thing I have learned over the years, it was from cleaning up roadkill from security folks who bought the hype, and believed that a service provider would solve all their problems. But you can’t outsource accountability. Then NSS went on to categorize some decision points for selecting a provider. And depending on what you are asking the provider to do, there are various nuances to making that selection. That’s fine. But ultimately there must be someone inside the organization responsible for the security program. Really responsible, and empowered to make decisions. That person is responsible for allocating resources to get the job done. That could mean using internal staff, deploying technology, leveraging managed services, or deeper outsourcing. I am not religious about any specific mix, but I am about the need for someone on internal to make those decisions. Share:

As we have discussed through this series, many types of attacks can impact the availability of your applications. To reiterate a number of points we made in Defending Against Denial of Service Attacks, your defenses need to be coordinated at multiple levels: at the network layer, in front of your application, within the application stack, and finally within the application. We understand this is a significant undertaking, and security folks have been trying to get developers on board for years to build security into applications – with little effect to date. That said, it doesn’t mean you shouldn’t keep pushing, especially given the relative ease of knocking down an application without proper defenses within the application. We have found the best way to get everyone on board is by implementing a structured web application security program that looks at each application in its entirety, and can be extended to add protections against denial of service attacks. Web Application Security Process Revisiting the process described in Building a Web Application Security Program, web applications need to be protected across the entire lifecycle: Secure Development: You start the process by building security into the software development lifecycle (SDLC). This includes training for people who deliver web applications, and improved processes to guide their activity. Security awareness training for developers is managed through education and supportive process modifications, as a precursor to making security a functional application requirement. This phase of the process leverages tools to automate portions of the effort: static analysis to help engineering identify vulnerable code, and dynamic analysis to detect anomalous application behavior. Secure Deployment: At the point where an application is code complete, and ready for more rigorous testing and validation, it is time to confirm that it doesn’t suffer from serious known security flaws (vulnerabilities) and is configured so it is not subject to any known compromises. This is where you use vulnerability assessments and penetration testing – along with solid operational approaches to configuration analysis, threat discovery, patch levels, and operational consistency checking. Secure Operations: The last phase of the process moves from preventative tools and processes to detecting and reacting to events from production applications. Here you deploy technologies and/or services to front-end the application, including web application firewalls and web protection services. Some technologies can protect applications from unwanted uses; others only monitor requests for inappropriate activity. To look at the specific aspects of what’s required to deal with AppDoS attacks, let’s look at each step in the process. Secure Development In this phase we are looking to build the protections we have been discussing into the application(s). This involves making sure the application stack in use is insulated against HashDoS attacks and no database calls present an opportunity for misuse and excessive queries. The most impactful protections are input validation on form fields to mitigate against buffer overflow, code injection, and other attacks that can break application logic. Understand that heavy input validation impacts application performance at scale, especially when under attack with a GET/POST flood or a similar attack. You should prioritize validating fields that require the least computational resources, and check them as early as possible. Extensive validation may exacerbate the flood attack and take down the application sooner, so you need to balance protection against performance when stress-testing the application prior to deployment. Also ensure your application security testing (static and dynamic) checks the application’s robustness against denial of service attacks, including shopping cart and pagination attacks. Secure Deployment When deploying the application make sure the stack has protections against the common web server DoS attacks including SlowLoris, Slow HTTP, and Apache Killer. You can check for these vulnerabilities using an application scanner or during a penetration test. Keep in mind that you will likely need some tuning to find the optimal timeout for session termination. Secure Operations Once the application goes into production the fun begins – you will be working with live ammunition. You can deploy an anti-DoS appliance or service, or a WAF (either product or service) to rate limit slow HTTP type attacks. This is also where a CDN or web protection service comes into play to absorb high-bandwidth attacks and intelligently cache static content to blunt the impact of random query string attacks. Finally, during the operational phase, you will want to monitor the performance and responsiveness of the application, as well as track inbound traffic to detect emerging DoS attacks as early as possible. You developed profiles for normal application behavior earlier – now you can use them to identify attack traffic before you have an outage. Finding the Right Mix As we have described, you have a bunch of options to defend your applications against denial of service attacks, so how can you determine the right mix of cloud-based, server-based, and application-based protections? You need to think about each in terms of effort and agility required to deploy at each level. Building protections into applications doesn’t happen overnight – it is likely to require development process changes and a development cycle or three to implement proper security controls to protect against this threat. The application may also require significant re-architecture – especially if the database-driven aspects of the applications haven’t been optimized. Keep in mind that new attacks and newly discovered vulnerabilities require you to revisit application security on an ongoing basis. Like other security disciplines, you never really finish securing your application. Somewhat less disruptive is hardening the application stack, including the web server, APIs, and database. This tends to be an operational responsibility, so you will need to collaborate with the ops team to ensure the right protections, patches, and configurations are deployed on the servers. Finally, the quickest path to protection is to front-end your application with an anti-DoS device and/or a cloud-based CDN/website protection service to deal with flood attacks and simple application attacks. As we have mentioned, these defenses are not a panacea – you still need to harden the stack and protect the application as well. But

  When you really see the underbelly of something, it is rarely pretty. The NFL is no different. Grown men are paid millions of dollars a year to display unbridled aggression, toughness, and competitiveness. That sounds like a pretty Darwinian environment, where the strong prey on the weak. And it is given what we have seen over the last few weeks, as behavior in the Miami Dolphins locker room comes to light. It is counterintuitive to think of a 320-pound offensive lineman being bullied by anyone. You hear about fights on the field and in the locker room as these alpha males all look to establish position within the pride. But how are the bullies in the Dolphins locker room any different than the petty mean girls and boys you had to deal with in high school? They aren’t. If you take a step back, a bully is always compensating for some kind of self-perceived inadequacy that forces him or her to act out. Small people (even if they weigh over 300+ pounds) make themselves feel bigger by making others feel smaller. So the first question is whether the behavior is acceptable. I think everyone can agree racial epithets have no place in today’s society. But what about the other tactics, such as mind games and intentionally excluding a fellow player from activities? I’m not sure that kind of hazing would normally be a huge deal, but combined with an environment of racial insensitivity, it is probably crossing the line as well. What’s more surprising is that no one stepped up and said that behavior was no bueno. Bullies prey on folks, because folks who aren’t directly targeted don’t stand up and make clear what is acceptable and what isn’t. But that has happened since the beginning of time. No one want to stand up for what’s right, so folks just watch catastrophic events happen. Maybe this will be a catalyst to change the culture. There is nothing the NFL hates more than bad publicity. So things will change. Every other team in the NFL made statements about how their work environments are not like that. No one wants to be singled out as a bully or a bigot. Not when they have potential endorsement deals riding on their public image. Like most other changes, some old timers will resist. Others will adapt because they need to. And with the real-time nature of today’s media, and rampant leaks within every organization, it is hard to see this kind of behavior happening again. I guess I can’t understand why players who call themselves brothers would treat each other so badly. Of course you beat up your little brother(s) when you are 10. But if you are still treating your siblings shabbily as an adults, you need some help. Maybe I am getting a bit judgmental, especially considering that I have never worked in an NFL locker room, so I can’t even pretend to understand the mindset. But I do know a bit about dealing with people. One of the key tenets of a functional and successful organization is to manage people in an individual fashion. A guy may be 320 pounds, an athletic freak, and capable of serious violence when the ball is snapped, but that doesn’t mean he wants to get called names or fight a teammate to prove his worth. I learned the importance of managing people individually early in my career, mostly because it worked. This management philosophy is masterfully explained in First, Break All the Rules, which shows how important corporate performance is for keeping happy employees who do what they love every day with people they care about. Clearly someone in Miami didn’t get the memo. And you have to wonder what kind of player Jonathan Martin could be if he worked in a place where he didn’t feel singled out and persecuted, so he could focus on the task at hand: his blocking assignment for each play. Not whether he was going to get jumped in the parking lot. Maybe he’ll even get a chance to find out, but it’s hard to see that happening in Miami. –Mike Photo credit: “Bully Advance Screening Hosted by First Lady Katie O’Malley” originally uploaded by Maryland GovPics 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 Introduction Defending Against Application Denial of Service Attacking the Application Stack Attacking the Application Server Introduction 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 What is it that you do? I have to admit that I really did not understand analysts or the entire analyst industry prior to joining Securosis. Analysts were the people on our briefing calendar who were more knowledgable – and far more arrogant – than the press. But they did not seem to have a clear role, nor was their technical prowess close to what they thought it was. I was assured by our marketing team that they were important, but I could not see how. Now I do, but the explanation needs to be repeated every so often. The aneelism blog has a nice primer on technology analyst 101 for startups. Long story short, some analysts speak with customers as an independent advisor, which means two things for small security vendors: we are told things customers will never tell you directly, and we see a breadth of industry issues & trends you won’t because you are focused on your own stuff and try to wedge

We looked at application denial of service in terms of attacking the application server and the application stack, so now let’s turn our attention to attacking application itself. Clearly every application contains weaknesses that can be exploited, especially when the goal is simply to knock the application offline rather than something more complicated, such as stealing credentials or gaining access to the data. That lower bar of taking the application offline means more places to attack. If we bust out the kill chain to illuminate attack progression, let’s first focus on the beginning: reconnaissance. That’s where the process starts for application denial of service attacks as well. The attackers need to find the weak points in the application, so they assess it to figure out which pages consume the most resources, the kinds of field-level validation on forms, and the supported attributes on query strings. For instance, if a form field does a ton of field-level validation or needs to make multiple database calls to multiple sites to render the page, that page would be a good target to blast. Serving dynamic content requires a bunch of database calls to populate the page, and each call consumes resources. The point is to consume as many of resources as possible to impact the application’s ability to serve legitimate traffic. Flooding the Application In our Defending Against Denial of Service Attacks paper, we talked about how network-based attacks flood the pipes. Targeting resource intensive pages with either GET or POST requests (or both) provides is an equivalent application flooding attack, exhausting the server’s session and memory capacity. Attackers flood a number of different parts of web applications, including: Top-level index page: This one is straightforward and usually has the fewest protections because it’s open to everyone. When blasted by tens of thousands of clients simultaneously, the server can become overwhelmed. Query string “proxy busting”: Attackers can send a request to bypass any proxy or cache, forcing the application to generate and send new information, and eliminating the benefit of a CDN or other cache in front of the application. The impact can be particularly acute when requesting large PDFs or other files repeatedly, consuming excessive bandwidth and server resources. Random session cookies/tokens: By establishing thousands of sessions with the application, attackers can overload session tables on the server and impact its ability to serve legitimate traffic. Flood attacks can be detected rather easily (unlike the slow attacks described in Attacking the Server), providing an opportunity to rate-limit attack while allowing legitimate traffic through. Of course this approach puts a premium on accuracy, as false positives slow down or discard legitimate traffic, and false negatives allow attack to consume server resources. To accurately detect application floods you need a detailed baseline of legitimate traffic, tracking details such as URL distribution, request frequency, maximum requests per device, and outbound traffic rates. With this data a legitimate application behavior profile can be developed. You can then compare incoming traffic (usually on a WAF or application DoS device) against the profile to identify bad traffic, and then limit or block it. Another tactic to mitigate application floods is input validation on all form fields, to ensure requests neither overflow application buffers nor misuse application resources. If you are using a CDN to front-end your application, make sure it can handle random query string attacks and that you are benefitting from the caching service. Given the ability of some attackers to bypass a CDN (assuming you have one), you will want to ensure your input validation ignores random query strings. You can also leverage IP reputation services to identify bot traffic and limit or block them. That requires coordination between the application and network-based defenses, but it is effective for detecting and limiting floods. Pagination A pagination attack involves requesting the web application to return an unreasonable amount of results by expanding the PageSize query parameter to circumvent limits. This can return tens of thousands or even millions of records. Obviously this consumes significant database resources, especially when servicing multiple requests at the same time. These attacks are typically launched against the search page. Another tactic for overwhelming applications is to use a web scraper to capture information from dynamic content areas such as store locators and product catalogs. If the scraper is not throttled it can overwhelm the application by scraping over and over again. Mitigation for most pagination attacks must be built into the application. For example, regardless of the PageSize parameter, the application should limit the number of records returned. Likewise, you will want to limit the number of search requests the site will process simultaneously. You can also leverage a Content Delivery Network or web protection service to cache static information and limit search activity. Alternatively, embedding complicated JavaScript on the search pages can deter bots. Gaming the Shopping Cart Another frequently exploited legitimate function is the shopping cart. An attacker might put a few items in a cart and then abandon it for a few hours. At some point they can come back and refresh the cart, causes the session to be maintained, and the database to reload the cart. If the attacker has put tens of thousand of products into the cart, it consumes significant resources. Shopping cart mitigations include limiting the number of items that can be added to a cart and periodically clearing out carts with too many items. You will also want to periodically terminate sufficiently old carts to reclaim session spaces and flush abandoned carts. Combination Platter Attackers are smart. They have figured out that they can combine many of these attacks with devastating results. For instance an attacker could launch a volume-based network attack on a site. Then start a GET flood on legitimate pages, limited in avoid looking like a network attack. Follow up with a slow HTTP attack so any traffic that does make it through consumes application resources. Finally they might attack the shopping cart or store locator which looks like legitimate activity.

  In our last post, we started digging into ways attackers target standard web servers, protocols, and common pages to impact application availability. These kinds of attacks are at the surface level and low-hanging fruit because they can be executed via widely available tools wielded by unsophisticated attackers. If you think of a web application as an onion, there always seems to be another layer you can peel back to expose additional attack surface. The next layer we will evaluate is the underlying application stack used to build the application. One of the great things about web applications is the availability of fully assembled technology stacks, making it trivial to roll out the infrastructure to support a wide variety of applications. But anything widely available inevitably becomes an attack target. The best example of this within the context of an availability attack is how hash tables can be exploited to crush web servers. Hash Collision Attacks We won’t get into advanced programming but you need some context to understand this attack. A hash table is used to map specific keys to values by assigning the value of the key to a specific slot in an array. This provides a very fast way to search for things. On the downside, multiple values may end up in the same slot, which creates a hash collision that needs to be dealt with by the application, requiring significant additional processing. Hash collisions are normally minimized, so the speed trade-off is usually worthwhile. But if an attacker understands the hashing function used by the application they can cause excessive hash collisions. This requires the application to compensate and consume extra resources to manage the hashing function. If enough hash collisions occur… you guessed it: the application can’t handle the workload and goes down. This attack was weaponized as HashDoS, an attack tool that leverages the fact that most web application stacks use the same hashing algorithm within their dictionary tables. With knowledge of this hashing algorithm, the attacker can send a POST request with many variables to create hash table chaos and render the application useless. Mitigation for this attack requires the ability to discard messages with too many variables – typically implemented within a WAF (web application firewall) – or to randomize the hash function using application-layer logic. A good explanation of this attack using cats explains HashDoS in layperson’s terms. Remember that any capabilities within the application stack can be exploited, and given the open source nature of these stacks probably will. So diligence in selection of a stack, ensuring secure implementation, and tracking security notices and implementing patches are all critical to ensure application security and availability. Targeting the Database As part of the application stack, databases tend to get overlooked as a denial of service attack target. Many attackers try to extract the data in the database and then exfiltrate it, so knocking down the database would be counter-productive. But when the mission is to impact application availability or to use a DoS as cover for exfiltration, the database can be a soft target – because in some way, shape, or form, the web application depends on the database. If you recall our Defending Against Denial of Service Attacks paper, we broke DoS attacks into network-based volumetric attacks and application-layer attacks. The issue with databases is that they can be attacked using both tactics. Application servers connect to the database using some kind of network, so a volume attack on that network segment can impact database availability. If the database itself is exploited, the application is also likely to go down. Either way the application is out of business. Database DoS Attacks If we dig a little deeper into the attacks, we find that one path is to crush databases using deliberately wasteful queries. Other attacks target simple vulnerabilities that have never been patched, mostly because the need for continuous database uptime interferes with patching, so that it happens sporadically or not at all. Again, you don’t need to be a brain surgeon to knock a web application offline. Here are some of the attack categories: Abuse of Functions: This type of attack is similar to the slow HTTP attacks mentioned in the last post – attackers use database functionality against you. For example, if you restrict failed logins, they may blast your database with bad password requests to lock legitimate users (or applications) out. Another example involves the attackers taking advantage of database autoscaling, blast it with requests until so many instances are running that the database falls over. Complex Queries: If the attacker gives the database too much work to do, it will fall over. There are many techniques, including nested queries & recursion, Cartesian joins, and the in operator, which can overwhelm the database. The attacker would need to be able to inject a SQL query into the database directly or from within the application for this to work, so you can block these attacks that way. We will talk about defenses below. Bugs and Defects: In these cases the attacker is targeting a known database vulnerability. This includes queries of death and buffer overflow to take down the database. With new functionality being introduced constantly, database attack surface continues to grow. And even if the database vendor identifies the issue and produces a patch (not a sure thing), finding a maintenance window to patch remains challenging in many operational environments. Application Usage: Finally, the way the application uses the database can be gamed to cause an outage. The best example of this is SQL injection, but that attack is rarely used to knock over databases. Also consider the login and store locator page attacks we mentioned in the last post, as well as shopping cart and search engine attacks (to be covered later) as additional examples of application misuse that can impact availability. Database DoS Defenses The tactics used to defend against database denial of service attacks really reflect good database security practices. Go figure. Configuration: Strong

Everyone has an opinion about security awareness training, and most of them are negative. Waste of time! Ineffective! Boring! We have heard them all. And the criticism isn’t wrong – much of the content driving security awareness training is lame. Which is probably the kindest thing we can say about it. But it doesn’t need to be that way. Actually, it cannot remain this way – there is too much at stake. Users remain the lowest-hanging fruit for attackers, and as long as that is the case attackers will continue to target them. Educating users about security is not a panacea, but it can and does help. It’s not like a focus on security awareness training is the flavor of the day for us. We have been talking about the importance of training users for years, as unpopular as it remains. The main argument against security training is that it doesn’t work. That’s just not true. But it doesn’t work for everyone. Like security in general, there is no 100%. Some employees will never get it – mostly because they just don’t care – but they do bring enough value to the organization that no matter what they do (short of a felony) they are sticking around. Then there is everyone else. Maybe it’s 50% of your folks, or perhaps 90%. Regardless of the number of employees who can be influenced by better security training content, wouldn’t it make your life easier if you didn’t have to clean up after them? We have seen training reduce the amount of time spent cleaning up easily avoidable mistakes. We are pleased to announce the availability of our Security Awareness Training Evolution paper. It discusses how training needs to evolve, and presents a path to improve training content and ensure the right support and incentives are in place for training to succeed. We would like to thank our friends at PhishMe for licensing this paper. Remember, it is through the generosity of our licensees that you get to read our stuff for this nifty price. Here is another quote from the paper to sum things up: As we have said throughout this paper, employees are clearly the weakest link in your security defenses, so without a plan to actively prepare them for battle you have a low chance of success. It is not about making every employee a security ninja – instead focus on preventing most of them from falling for simplistic attacks. You will still be exploited, but make it harder for attackers so you suffer less frequent compromise. Security-aware employees protect your data more effectively, it’s as simple as that, regardless of what you hear from naysayers. Check out the page in our Research Library, or download the Security Awareness Training Evolution (PDF) paper directly. 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: