Shift (Web App) Security Lefter
The concept of "shifting left" for appropriate IT concerns is growing. The notion is basically to shift more into the app dev delivery pipeline functions that, when applied earlier, can result in greater stability and security of the resulting code. Security is one of those functions that can yield significant benefits in terms of reducing the conflicts and errors that crop up in production and cost time and money the business would rather not spend. Most of the time the security functions proposed as being ready to "shift left" are those that relate directly to code: vulnerability scanning, automated patching, intrusion detection and similar services. What is rarely (in fact probably never until this post) mentioned is the benefits of shifting web application firewall functions left. There is good logic behind shifting this kind of functionality left, namely application affinity. Highly application affine services like web application security and load balancing and optimization are specific to an application. Not a protocol like HTTP, but to the actual application itself. Application security and optimization, in particular, often contain configurations that require understanding specific URIs (like RESTful API calls), the types of data being exchanged (and its formats), as well as identifying users and devices that may be specific to the app or specific portions of the app. That means a web application security policy is based pretty much on the application, which means that policy is good for that application alone. Matching data and URIs can (and does) introduce the potential for errors which means an application that breaks. When that error first shows up in production, heads roll. Time is spent, money is wasted and the caffeine budget for the week skyrockets and leaves everyone else drinking colored water for the rest of the month. Not good at all. Shifting the configuration and testing of these application affine policies lefter, into test, can be a significant boon in terms of eliminating most (hopefully all but, Heisenberg) conflicts or errors and ensuring a smoother, faster and less complicated roll out through the production pipeline. The increasing availability of software and virtual editions of traditional web application firewall services means the ability to provision these services in a broader number of environments and ensure higher levels of access lefter in the deployment pipeline. Shifting web application security lefter also means the ability to apply vulnerability scanning to the web application security service while it's protecting the application under test, giving security ops and dev a better understanding of the interaction between the two as well as the opportunity to tweak policies to ensure proper (expected and desired) behavior. Policies, especially those that might be encapsulated in template form, are easy enough to move between environments and can be treated as code - stored in repositories and versioned for future use. The availability of APIs and templates along with virtualization of traditionally network-hosted application affine services makes it possible for organizations to shift security lefter and achieve real gains in optimizing the production pipeline process.App Security: The Elephant in the Cloudy Room
Okay, kids. It's time we had "that talk". You know the one, the one you've been whispering about with your friends but heretofore were afraid to actually ask about because of course everyone else knows about it and you didn't want to appear, well, not cool by admitting you didn't really know. Except they don't, or at least if they do, they aren't talking about it either. And it's really past time we talked about taking the right precautions when using the cloud. You know, how to protect your apps in the cloud from infection and attack. Yes, today we're finally going to talk about application security in the cloud. Not encryption. Not identity and access management. And not network security. Application security. Because of all the documents, research, advice and general discussions on "cloud security" available on the vast Internet today very few* of them mention the words "app security." I can find research and statistics about the use of encryption, about who should (and isn't) protecting data in the cloud, and who's using what kind of identity and access management to gate access to apps anywhere and everywhere. But on the topic of application security? Nada. Nothing. Zilch. Zero. Which is really quite surprising (and disturbing) given that web apps are the second leading cause of security incidents for financial services, just behind the evil-sounding crimeware according to the most recent Verizon Data Breach Investigation Report (DBIR). It's also surprising upon doing a bit of analysis on the top 25 breaches this century and finding out that nearly half (44%) were executed through a web application. It's also disheartening because there seems to be a correlation between a decreasing security posture and the migration of applications to the cloud. The reality is that encryption is not a panacea. Let me repeat that, this time in all caps to emphasize how serious this is: ENCRYPTION IS NOT A PANACEA. Neither is network security or identity and access management. All these things are good, but individually they are only one part of a much larger protection scheme. A protection scheme that should - but often does not - include application security in the mix. Network security isn't going to stop an HTTP DDoS attack. Identity and access management isn't going to stop the exploitation of a web platform vulnerability like Heartbleed or Apache Killer. Encryption isn't going to stop an SQLi. Encrypting malicious code just hides it from the myriad services in the network designed to find them. The application is, by its purpose, a public-facing resource. We put it out there and expect - nay, we encourage, we entice, we beg - consumers to interact with it. To use it. To install it. To visit it often. It is an application world, and that means applications are critical to every aspect of business, whether that's customer-facing, employee-facing or internal-systems running. We rely on applications for just about everything we do these days, and yet when we mention security we never seem to remember it. It's really about time we start paying more attention to application security, and not just data security or network security or encrypted communications. Data is most vulnerable when it's in process in the application. That's because at that point it is in plaintext, and it is completely under the control of that application. The application can display it, modify it, and deliver it to whomever (or increasingly whatever, given the rise of bots and spiders and malware) can coax it out. That means we need to pay more attention to securing applications against exploitation and attack. From the platform (the web or app server) to the protocols (TCP and HTTP) to the actual code itself. We need to scan and scrub and discover and defend against the myriad methods used by attacks to exploit the entire application stack. Web application attacks doubled in frequency from under 20% in 2012 to 40% in 2013 according to F-Secure Labs, and Neustar found in 2014 that 55% of DDoS targets experienced smokescreening (volumetric DDoS as a cover for the real, application layer attacks) with nearly 50% having malware/virus installed and 26% losing customer data. Application attacks are a real and significant threat, especially as they migrate to the cloud where fewer options for protecting them may be available. The native services available in the cloud focused on security are all about access and encryption. None of them are "application layer" security and none provide the coverage necessary to inspire confidence in withstanding an attack designed to disable, corrupt or exfiltrate data by exploiting the application itself. That means you need another solution; another service designed to protect applications and the data it is responsible for handling in the cloud just as you do in the data center. That may mean a cloud-enabled WAF (web application firewall) or WAF as a Service or at a minimum a thorough application of the best practices recommended by OWASP on every application deployed in the cloud. Cloud security may be viewed as a shared responsibility, with the provider and the customer taking on the chore of different aspects of securing "the cloud" but application security is 110% the responsibility of the one who puts that application in the cloud in the first place. Consider this interview (via The Register) with AWS head of global security programs Bill Murray (emphasis mine): “Security at AWS is a shared responsibility between AWS and customers,” Murray said in a recent interview. He is responsible for AWS security, spanning physical security of Amazon data centres, while also handling warrants and subpoenas from law enforcement. “Customers are responsible for protecting everything from the guest operating system they run on AWS up through the applications they are running,” he told El Reg. We are responsible for the host OS and the VM and everything down to the concrete of the data centre floor.” “We are asked this question a lot: 'What keeps you up at night?' What keeps us up at night in AWS security is the customer not configuring their applications correctly to keep themselves secure,” Murray said. That's you, and that means you need to consider carefully what services and solutions you're deploying to protect that application from what inevitably looks like the attack that's going to come your way. Application security isn't like an expensive bodyguard. It's not something that only the VIP apps get. It's more like personal security, and it's something every application that presents itself in public should have. And that's true whether those apps are in the data center or in the cloud. * I say "very few" but honestly, I could not find even one. Mayhap that's my Google fu failing, but more likely it's because no one seems to want to talk about it.The Internet of Security Things
No, this isn't a tirade on the security of IoT. It's about story about change. Specifically, change and its implications on security. Change is constant. There's a million different axioms and proverbs about change, so it's really hard to choose just one to sum up how it impacts security. Inarguably it does. And right now there's a lot of change going on that's impacting security. "Micro" movement like microservices and microsegmentation are dramatically changing perimeters and breaking apart traditional "edge" security into distributed pockets of security, each architected specifically for the application or architecture it's protecting. The nearly ubiquitous use of HTTP as the de facto application transport protocol (it's the new TCP, you know) has led to an increasing rise in the elimination of network access and an increase focus on application access, as well as more attention being paid to the security dangers inherent in the application layer. The rise of connected things both internal and external to the data center are of course a concern; putting pressure on networking and security operations alike to adjust in rapid fashion to an increasingly complex array of connections, applications, devices, people and data. And of course attacks are on the rise, with the DPS of a DDoS having doubled in just the past few years. These are all changes. Some good, some bad, some inherently neutral, but all impacting security in one way or another. Out of these interconnected and interrelated trends comes four key areas of concern: web application security, scale and capabilities of access and identity management, operationalization and DDoS protection mechanisms. The Internet of Security Things is a quick look at change across all four of these areas and what we can do to start addressing them.Cloudy with a Chance of Security
We found all manner of interesting practices and trends as it relates to cloud and security in our State of Application Delivery 2015 report. One of the more fascinating data points was a relationship between security posture and cloud adoption. That is, it appears that the more applications an organization migrates to the cloud, the less strict its security posture becomes. Really. I was a bit disturbed by that, too. At least at first. The reality is that simply asking about "applications in the cloud" isn't enough. It's perfectly reasonable to expect an organization that pays careful attention to application security (securing all three Cs) in the data center might not appear to be as careful if those applications move to a SaaS offering. Not because the attitude toward security has changed, mind you, but because there's no means for an organization to apply that level of scrutiny to a SaaS. They can't deploy a WAF inspect inbound requests and outbound responses, after all. But if those apps are migrating to an IaaS environment, where services like web application firewalls and application aware services can be deployed, then we're looking at a very different story. After all, if you can and choose not to, then you're purposefully degrading your security posture; hedging your bets that "in the cloud" is somehow safer than "in the data center." I'd guess that in the case of our results with respect to cloud and security practices, that there's some of both these scenarios (and probably some other ones, too) that explain the abandonment in security practices with increases in cloud presence that the data shows. Lesson learned: don't just ask about migration to "the cloud"; specifically dig in and ask whether an app is migrating to SaaS* or to IaaS or even to PaaS. That's important, because it has an impact on the amount and type of attention paid to securing that app. SaaS is more likely to be governed by an identity federation architecture that enables corporate oversight over access. IaaS is more likely to be protected by application layer security services but not traditional network security services (in the sense that the organization deploys and manages these services, of course cloud providers include these services, making them not only redundant but unnecessary). What we can, say, however, is that thanks to the migration of applications to cloud environments organizations certainly have less control over access to and security of those applications, whether intentional or not. The movement of apps toward the cloud has introduced fewer security practices on the part of the organization, and that might be a wee bit problematic. "Out of sight, out of mind" is not an appropriate attitude for information security, after all. I'll leave you with this infographic full of data related to cloud and security (and cloud security, I suppose) and a reminder that we have plenty more security-related (and application service-related, of course) data in the full report, which you can get here , along with archives of webinars exploring the data and concepts in more depth. If you're at RSA this week, feel free to stop by the F5 booth (it's the one with the big red ball ) and find out more about our full-stack approach to security, including apps "in the cloud". * I still maintain SaaS isn't really cloud computing, it's a hyper-scaled application on the Internet. We usually call those "apps", not "cloud". Call me Lori Quixote. It's my windmill, I'll tip at it if I want to.F5 Synthesis: Delivering Web Application Security in the Cloud as a Service
Web application security. Everyone knows how important it is (and if they don't, they should) and yet the complexity of managing services that provide it often result in, shall we say, less than holistic coverage of applications. At least that seems to be the case given some rather disturbing statistics around the rise of bots and malware, which can often be deposited thanks to some overlooked or obscure web application vulnerability. Some in the application itself, others in the platform (remember Apache Killer?), and still others in the protocols used by just about every web application in existence (HT to Heartbleed). Web application security is, after all, a stack. In fact, throughout the 21st Century, nearly half of the biggest (in terms of records exfiltrated) breaches were the result of an exploited web application vulnerability. The exfiltrated data ran the gamut from credentials to personal information to credit card numbers. At the same time, everything seems to be taking a back-seat to speed of application deployment. More than 9 out of 10 executives reported they face increased pressure "to release apps more quickly" according to a CA and Vanson Bourne 2014 survey. Other survey and research shows the network is still in the way in this respect, taking much longer to push an app through the production pipeline than organizations would like. 39% of respondents say "slow manual processes to reconfigure infrastructure to accommodate change" and 31% "slow provisioning of new applications" are key IT pain points, according to EMA research. To address these pain points, agile and DevOps approaches are expanding to include operationalization of network and application services, but rarely mention security. Some worry that applying agile development methodologies to security could be akin to promoting the deployment of minimal viable security policies. Fast, yes, but incomplete and only covering the most obvious of attacks. Leaving the application - and organization - vulnerable to attack. And then you add cloud to the picture, which is like adding that 4th variable in a polynomial math problem. The complexity is exponential and often seems unsolvable. It's not just a matter of putting the protections into place for cloud hosted applications; it's also a matter of managing those protections in a completely different context - a new environment that may or may not be supportive of the security solutions needed to fully cover the app. Yet security professionals are still experiencing pressure to step up the pace with respect to deploying security as it relates to apps moving through the production pipeline and support apps deployed in cloud computing environments. So basically the ultimate solution is something that's fast to deploy without sacrificing completeness, covers the entire application security stack and supports both on-premise and cloud deployed applications with equal alacrity. Oh, and it can't cost an arm and a leg, either. Cost efficacy is important to cost-conscious C-everything-O's today. One possible solution that meets all the criteria is web application security - as a service. Security Meets SaaS with F5 Silverline Web Application Firewall F5 Silverline Web Application Firewall (WAF) is a subscription-based, cloud-hosted "as a Service" security solution. Based on BIG-IP ASM (Application Security Manager), recognized as the most scalable WAF on the market and deployed in more datacenters worldwide than any other WAF, F5 Silverline WAF allows organizations to remove the complexity of WAF management, increase the speed with which new policies are deployed, and keeps policies consistent for applications moving to - or from - the cloud. More importantly, perhaps, it keeps apps protected. After all, NSS Labs recommends BIG-IP ASM as a web application firewall based on tests that demonstrate 99.89% overall security effectiveness with minimal false positives (.124%). That may be why when we asked our customers how confident they were in being able to withstand an application security layer attack, 92% responded they were confident. Full-stack confident. F5 Silverline WAF is supported by highly specialized security experts who build and maintain web application firewall policies to defend organizations against web attacks and help achieve regulatory compliance in a hybrid (across traditional and cloud) environments. Because it's based on BIG-IP ASM, it inherits technologies unique to F5, like iRules, which provides the flexibility and agility needed to respond to new attacks in real-time, and iApps, which enable organizations to operationalize application security in a way that emphasizes standardization of core security policies as a way to ensure consistency in an increasingly hybrid architectural world. F5 Silverline Web Application Firewall joins F5 Silverline DDoS Protection as the second service available from our cloud-based application services platform. F5 Silverline Web Application Firewall extends F5 Synthesis' ability to deliver the Software Defined Application Services (SDAS) organizations need to defend and deliver applications to any one, at any time from any where. Because it's based in the cloud, it can extend its protection against bots, spiders, malware and attacks to applications in cloud environments and primary or secondary traditional data centers with less friction and impact on performance than would be required to extend an on-premise solution to applications deployed outside the same on-premise location. The complexity and costs associated with replicating and enforcing consistent and proven web application security policies across traditional and cloud environments results in higher expenses and introduces latency into response time when faced with threats and extends timelines in order to maintain regulatory compliance. Organizations must choose between employing specialized IT security teams in-house—resulting in higher expenses and increased time to deploy policies—or offloading the complex WAF policy management and compliance to a service to drive efficiencies. F5 Silverline Web Application Firewall enables IT organizations to meet the strict demands of corporate security policy and compliance without sacrificing consistency or speed by mitigating the complexity of web application security in not just in a hybrid cloud architecture, but in any architecture.State of Application Delivery 2015: Full-stack Security Confidence
Security is one the more prominent of the application service categories, likely due to its high profile impact. After all, if security fails, we all hear about it. The entire Internet. Forever. So when one conducts a survey on the state of application delivery (which is implemented using application services) you kinda have to include security. Which of course, we did. But when we asked questions about security we got down in the dirt. We asked the expected questions like what security services organizations were deploying (spoiler: it's a lot of them) and which ones they were planning on deploying. But we also asked some deeper, probing questions about web application security practices and their confidence in being able to withstand an application layer attack. We asked that question because reports and data all point to the same inescapable conclusion: application layer attacks are on the rise. What's perhaps more disturbing is that it's taken us (as in the industry at large) this long to pay more attention to it. Look back over the past 15 years of breaches and you'll find that nearly half of the biggest breaches (in terms of records exposed) were due to a web application compromise. So it's kind of an important topic and why it was both surprising and heartening to find that 92% of our customers were "confident to highly confident" in their ability to withstand such an attack. What makes them so confident? That's where the digging in the dirt paid off. Turns out there's a high correlation of specific web application security practices with level of confidence in withstanding an attack. You can read more about that here, in "Web App Security Practices of the Highly Confident." That doesn't mean that traditional attacks aren't still a problem. They are. You might recall that the DPS of a DDoS has doubled and what's more interesting is that a 2014 Neustar survey found that 55% of DDoS victims experienced "smokescreening - where criminals use DDoS attacks to distract IT staff while inserting malware to breach bank accounts and customer data" - with nearly 50% having malware/virus installed and 26% losing customer data. Which means it's a growing imperative that organizations feel highly confident about their ability to withstand not just an app layer attack, but a volumetric attack too - at the same time. With the staggering growth of bandwidth consumed by volumetric DDoS attacks, it's no surprise that experts and organizations alike are recognizing the need for a new approach to mitigating these attacks. The approach most often mentioned is a Hybrid DDoS Protection Architecture; one that combines the seemingly limitless bandwidth available to DDoS protection in the cloud that's needed to fend off an attack with an on-premise solution. One that, to be completely covered, continually stands guard against the inevitable app layer attacks. For even more insight into the current state of security and application delivery, check out the full "State of Application Delivery 2015" report. And while you're there grabbing the goods, you can sign up for our next webinar in the State of Application Delivery 2015 series focused on ... wait for it.... wait for it... you guessed it, security. Security: Mitigate DDoS Attacks Effectively with a Hybrid DDoS Protection Architecture DDoS threats are constantly evolving. While traditional attacks aimed at filling Internet pipes are still common, application-targeted attacks are becoming more prevalent. As attacks continue to grow in complexity and size, and span multiple vectors, organizations must evolve their defense. Learn how a hybrid DDoS protection architecture can help secure your business from today’s sophisticated attacks.F5 Threat Analysis: It's a mad, mad, mad, mad ... bot
Madness. It's an aptly named bot, as it's likely to evoke just that reaction in those who find it lurking in their systems or at whom its sets it sights. A disturbing trend illustrated by the focus of our latest threat analysis is the increase in attention being paid to application layer attacks. Not just directly, but also as part of larger volumetric attacks. Increasingly application layer attacks are seen as part of a larger attack that takes advantage of volumetric network DDoS techniques as a "smokescreen" to hide their real intent. A 2014 Neustar report found that 55% of DDoS attack victims experienced application layer attacks at the same time that successfully deposited malware (over 50%) or exfiltrated customer data (26% of victims). While the focus of our analysis today, Madness, appears to be solely concerned with Denial of Service and not intended or capable of perpetrating attacks designed to exfiltrate or corrupt customer or corporate data, its increasing capabilities at layer 7 are indicative of a general trend toward attacks on applications rather than the network. That's the bad news. The good news is that organizations overwhelming feel confident in their ability to withstand such attacks; our State of Application Delivery 2015 survey found that 92% of customers were confident to very confident they were ready and able to handle such attacks. Given that a majority protect all three attack surfaces "all the time", this confidence is likely warranted. But as complacency is as dangerous to security as complexity, it's always a good idea to know thine enemy - particularly with respect to what weapons their arsenals contain. With that proverbial advice in mind, let's get a quick look at Madness, shall we? Madness is, according to its authors, a superior successor to notorious DDoS malware families “BlackEnergy”, “gbot”, “DirtJumper”, “Darkness Optima”, “iBot” and “w3Bot”. Though the bot employs standard persistency techniques its attacks show an increasing level of sophistication. In terms of the former it employs a fairly traditional Marco Polo technique of constantly polling for the existence of specific registry keys that, if found to be missing, will be added again. On the attack front, however, Madness displays a growing awareness of the richer attack surfaces at layer 7 (application). While supporting traditional network-based DoS capabilities, Madness also offers a number of application layer attacks with growing detection evasion options. Madness' HTTP flood options can be categorized into low-level and high-level attacks. Low-level attacks allow the attacker to control all aspects of the HTTP request. By enabling complete control over the request, attackers can better construct requests that can bypass many DDoS protection mechanisms. Higher-level attacks provide automatic handling of all protocol level concerns such as request construction, TCP connection management, caching, cookies and even redirections. Madness adds an interest twist to traditional HTTP GET flood attack by adding a slight delay in between the initial GET request and the completion of the request as indicated by the standard carriage return-line feed combination ("\r\n"). As this version of the attack does not include many of the traditional HTTP request headers - it comprises only the Host header - attacks from Madness using this attack should be fairly easy to detect. Our Security Research Team, which is dedicated to performing research of DDoS, web, mobile and malware threats, has put together a comprehensive analysis of Madness. You can get the full report here, which includes details on: Persistency techniques C&C methods Attack types and capabilities Mitigation guidance They've also penned a technical blog detailing their analysis. Stay safe out there!The bigger the base the larger the blast radius
At the end of the year, WhiteHat Security posted an interesting blog titled, "The Parabola of Reported WebAppSec Vulnerabilities" in which a downward trend in web application vulnerabilities (as collected by the folks at Risk Based Security's VulnDB) was noted beginning in 2008 after having been on an upward trend since 1994 (hence the use of parabola to describe the histogram of reported vulnerabilities. See hastily composed diagram on left. A very angular looking parabola but a parabolic shape nonetheless ). The author further postulates some possible explanations for this trend. including a "more homogeneous Internet", which is explained as: It could be that people are using fewer and fewer new pieces of code. As code matures, people who use it are less likely to switch in favor of something new, which means there are fewer threats to the incumbent code to be replaced, and it’s therefore more likely that new frameworks won’t get adopted. Software like WordPress, Joomla, or Drupal will likely take over more and more consumer publishing needs moving forward. All of the major Content Management Systems (CMS) have been heavily tested, and most have developed formal security response teams to address vulnerabilities. Even as they get tested more in the future, such platforms are likely a much safer alternative than anything else, therefore obviating the need for new players. That seems a logical (and likely) explanation. The continued refinement of highly leveraged code ultimately reaps the benefit of being more secure. It's like realizing the benefits of a thousand code reviews instead of the usual three to five colleagues. Certainly the additional scrutiny has rewards in the form of greater stability (fewer kinks need to be worked out because, well, they've already been worked out) and improved security (almost all the holes have been found and patched). The code base is also likely well-documented and supported by an active community, making it an attractive choice for developers looking for a framework or system with a robust, extensible repository of "extras" and "options". It's a win-win-win situation. I know what you're thinking - there's one too many "wins" in that equation. There's the developers of the framework or system and the consumers. It should be win-win, shouldn't it? Au contraire, mes amis! The third win is, in fact, for the bad guys. The attackers. The would-be infiltrators and destroyers of your web application. Consider that two of the most disruptive (and effective) vulnerabilities of 2014 were discovered in just such code bases. Long-lived, well-supported, widely distributed. Perpetrated against platforms that, like application frameworks and platforms, are highly disruptive (and costly) to patch when such vulnerabilities are discovered. [ Heartbleed and Shellshock were highly disruptive and perpetrated against industry de facto standard technology ] Attackers, on the other hand, have a field day because the homogenous and entrenched technology means many weeks (perhaps months) of systems ripe for exploit. It's harvest time for the bad guys. Now, I'm not saying we shouldn't be using well-established, "seasoned" platforms. I am saying that (potentially) diminishing vulnerabilities does not mitigate all the risk associated with a platform or technology. Certainly every year the platform is in use, the risk of vulnerabilities existing decreases. But this also means the damage from the exploitation of a heretofore undiscovered vulnerability increases because continued adoption and use of the technology expands its blast radius. In other words, there is a converse relationship between the distribution size of an established (and assumed mostly-secure) technology platform and the potential damage incurred by the discovery of a vulnerability in it. It is important to note the author states, "Even as they get tested more in the future, such platforms are likely a much safer alternative than anything else". Not safest. Not risk-free. Safer. What that means is you need to consider not only the likelihood of an attack for established platforms and software (which is admittedly growing lower by the day) but the blast radius should a vulnerability be discovered. If all your sites are running on platform X and a vulnerability is discovered, what's the impact to your business? Conversely, that risk must be weighed against the risk of custom or less well-established platforms being riddled with vulnerabilities and consuming valuable time and effort in constant evaluation and remediation cycles. Information security decision making is a constant balancing act of risk versus reward, disruption versus dependability. What 2014 taught us is we should expect that a vulnerability will be discovered in even the most well-established platform, and plan accordingly.
