Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Application Security for Modern Operations Teams

DZone's Guide to

Application Security for Modern Operations Teams

For the past 14 years, the OWASP Top Ten has remained virtually unchanged. One expert shares his thoughts on how to bring AppSec up to speed.

· Security Zone
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

This article is featured in the new DZone Guide to Proactive Security. Get your free copy for more insightful articles, industry statistics, and more!

You know the drill: XSS, SQLi, command execution. It’s 2017, yet for application security, it might as well be 2003. That’s not just rhetoric — the same recommendations that the Open Web Application Security Project (OWASP) delivered as the OWASP Top Ten in 2003 has largely remained unchanged over the last 14 years. Along with that, the same defensive practices of input sanitization and parameterized queries are largely still used as the best remedy to application security woes. While these are certainly good practices, they are incomplete in today’s modern application ecosystem — they focus solely on developer remediation and offer little to no insight into how operations teams should approach application security.

During the last decade, operations teams have seen a dramatic shift that is still unfolding across the industry. The most forward-thinking teams have already adopted DevOps practices, and the rest are in the process of doing so. Services are being decoupled from their once-monolithic applications into microservice architectures composed of APIs and third-party providers. Deploy rates are moving from once-a-quarter to on-demand, usually multiple times a day. Developers and operations staff now work together to rotate on-call duties and promote availability and reliability of systems.

These changes paint two opposing pictures: security is still largely stuck relying on true-but-tired defensive measures from the days of slow-moving IT, and operations that have radically transformed into a fast-moving IT delivery pipeline. Security practices such as static code analysis and long, drawn-out approval processes continue to slow down the software delivery pipeline with more and more questionable returns. However, there is a better way: operations teams can help security go faster and reduce threats at the same time. 

Modern Operations’ Impact on Application Security

There are four ways that operations teams can strengthen application security while simultaneously helping to speed development and response to threats as they happen. The four ways to achieve these goals: Instrument Business Logic, Focus on Authenticated Traffic, Monitor Account Actions, and lastly, Complete the Loop from Ops to Dev to Security. Let’s look at each of these areas in turn. Addressing each of these four areas should help answer the two questions that application owners and security engineers are asking: Am I being attacked right now? Are the attackers having success?

Instrument Business Logic

Operations has always been good at monitoring CPUs and memory. However, this is becoming more and more irrelevant in the modern architecture patterns of cloud, microservices, and serverless. Instead, they must focus on instrumenting business logic inside the application. This often gets overlooked by operations and security teams. What does “business logic” mean? Some examples of business logic are: transfer of funds, viewing an account balance, creating a new account, adding a credit card, or changing a customer address. For each application, the specific business logic requirements are unique, requiring an effort to gather the application owners and determine what to instrument.

Try not to go overboard here and attempt to instrument everything. Instead, work to span across development, operations, and security to identify the highest-risk business logic. If someone had full access and was able to take advantage of our application, what would they do? Of course, if you have the expertise in-house, doing a threat model is a great exercise to help arrive at these requirements. Even if you start with just a handful of application flows, the instrumentation of business logic helps establish a baseline for the application. It can then be monitored for variation that might suggest the application is under attack.

Focus on Authenticated Traffic

Every single day, websites are under attack. Most likely, a day doesn’t go by without your site being targeted by some vulnerability scanner or attack tools. This is the norm in today’s internet, and alerting on every XSS attempt you detect will overwhelm your team. SQLi, XSS, and command execution are a lot more interesting in the context of a logged-in user.

Focus on application instrumentation and monitoring that can tell the difference between authenticated users and unauthenticated users. Are any of my customers trying to attack me? Has an account been breached? Looping this instrumentation back to customer support specialists and security teams is key for finding users or partners that have had account credentials stolen or hacked.

Monitor Account Actions

Instrumentation comes easy at the server level. But the threat landscape has shifted. Today’s targets, more often than not, are user accounts and personal identification information. A whole class of attacks known as Account Takeovers (ATO) is on the rise. The ATO storyline is a familiar one — millions of accounts are compromised, and data is leaked to the internet and sold to the highest bidder or to some nation-state hacking group. These accounts are valuable because they include working credit cards and user data. Instrumentation for ATO must include login success, login failure, password reset request, successful password reset, email address change, and username change. Just like in business logic instrumentation, determining what to instrument will require collaboration across teams. One other leading indicator of ATO is traffic source. Knowing your users’ normal geography and network address means substantial differences should set off alerts. “Do I know the normal rate for login failures and success across my entire user base? What IP address blocks do my users normally come from?” Knowing the answers to these questions can help you defend your users’ accounts.

Complete the Loop From Ops to Dev to Security

Monitoring multiple dashboards to view pertinent security information is not a valid option in the modern IT organization. More and more teams have adopted the DevOps pattern of ChatOps, wherein tools are integrated into team chat systems like Slack or HipChat. This puts tools where developers and operations engineers already are. When the login portion of your site is seeing suspicious traffic, it makes sense to get that information in front of the team of developers and operations staff that support login functions. Closing the feedback loop doesn’t just mean chat. Integration with other systems like ticketing systems, monitoring systems, and even SIEM or logging systems helps enhance the communication between teams.

The focus here is providing tactical security feedback to the teams that are responsible for the application. This creates a security self-service model rather than siloing security information with just the security team. When developers, operations, and security teams distribute security feedback loops throughout the system, security becomes a team sport. Every possible chance to create a feedback loop between development, operations, and security creates a new opportunity to get more eyes from different disciplines to participate together in defending the application. Feedback loops provide a virtuous cycle. They enable security to no longer be seen as the organization that slows things or inhibits agility, but instead integrates application security feedback and acts as a true business enabler.

Moving Forward

Through these four modern approaches to application security, it is possible to go faster and reduce threats at the same time. A new day is on the horizon. These improvements move application security out of the silo of security and into the DevOps world. Security becomes a team sport, and the goal becomes achieving better security together, which ultimately leads to more defendable systems and applications.

There are two questions that application owners must ask: “Am I being attacked right now? Are the attackers having success?” Through implementing these four approaches, you will feel more confident in your ability to answer these questions.

This article is featured in the new DZone Guide to Proactive Security. Get your free copy for more insightful articles, industry statistics, and more!

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,application security ,appsec

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}