IT security, it used to be said, resembles a certain type of candy: hard on the outside, and soft on the inside. This metaphor depicts the security approach that focuses on hardening the perimeter of the data center to prevent intrusion by external malefactors, while assuming that access by employees is benign and therefore does not require specific protective measures. If that metaphor was ever appropriate, it is certainly no longer tenable in today's world when you consider that:
Most application access comes from outside the company's perimeter, with a heterogeneous user mix of employees, customers, and partners. While some IT organizations assume that VPN use makes applications more secure, in one sense that is a false belief, since VPNs typically bypass many perimeter protections and offer direct access to applications.
This access comes from a bewildering array of devices. Moreover, individual users may use several different devices to access applications, depending on where they happen to be when using them. For example, an employee may access an application from a laptop while sitting in a coffee shop, and then use a mobile phone later to access it from a customer site.
The looming IoT explosion means many users will access applications with no ability to present a password for authentication.
From static to erratic
Another issue with the traditional approach to security is that it assumes a static computing environment and application topology. In the past, applications ran on physical or virtual servers that were configured and connected in unchanging arrangements. Before deployment, development groups would engage the IT security team to audit the application and recommend security measures. Once implemented, those measures could be assumed as consistent and ongoing.
The move to public cloud computing and applications that experience highly erratic traffic patterns means that static security approach is broken:
By definition, public cloud environments prevent individual users from installing perimeter security measures. Whatever security the user wants to implement, it must be associated with application-level resources.
The fact that public cloud infrastructure can fail (e.g., servers or disks experience hardware outage) means that assumptions about infrastructure consistency are no longer tenable.
The erratic traffic patterns of next-generation applications means that resources are constantly being added and removed from the application topology. The set-and-forget security approach is inadequate for this dynamic topology world.
Finally, next-generation applications require much more frequent code changes as you deploy new functions. Traditional update cadences of six to twelve months are moving to monthly, weekly, or even daily deployments. A security approach that assumes manual installation and configuration will represent a roadblock in this accelerated application life cycle environment.
7 recommendations for app-focused security
For these reasons, enterprise IT must move to a new security approach, one that can address the new reality of next-generation applications.
All this doesn't mean security isn't important, or that it should be short-changed in the urgency of creating a digital enterprise. Far from it. Security is, if anything, more important in this new world. The truth is that IT's role is changing dramatically, from being a back-office process automation function to deploying applications that are the primary way the enterprise conducts its business.
Security failures now represent threats to the company's customer and employee relationships, brand, and even stock market valuation. Just witness the carnage left by the Target and Sony hacks.
Given the importance of security, then, along with the changing conditions in which IT security must operate, what are best practices that IT organizations should pursue to meet their security responsibilities? Here are seven recommendations for application-focused security:
1. Treat infrastructure as unknown and insecure
This should be obvious, but since cloud providers are commonly rather opaque with regard to their security practices, the default position for enterprises should be to assume that their applications must implement enough measures to suffice for complete security. By the way, this isn't a bad approach for on-premises environments, either. As the Target and Sony examples illustrate, corporate security measures may be inadequate, so implementing application-level measures is appropriate. In any case, it's often unknown during development exactly where the application will be deployed, so implementing security measures that do not assume security capabilities for a particular environment is a good idea.
2. Apply security to each application component
Analyze each component to determine what security measures are appropriate for it. Certain components (e.g., program execution resources) will require intrusion detection/prevention systems. Others (e.g., database or storage) will require access controls that prevent non-application components from touching data elements. Of course, network access controls that allow only approved users or application components from sending traffic to other parts of an application are critical (this latter area is rife with issues, as configurations are left too open for the application life cycle stage (i.e., during development it may be appropriate to maintain a very open component firewall configuration) but when an application moves to final staging or into production, firewall access should be constricted so that only appropriate traffic sources can access application resources.
3. Automate installation and configuration of security components
This is difficult but critical. The lengthy audit, recommendation, and installation/configuration processes that were acceptable in the past are completely inadequate for next-generation applications. Worse, manual processes are subject to human error in execution and may be bypassed by a sense of urgency and business pressure. While the move to automation is a challenge, most security organizations find the new approach an improvement; automation ensures that recommended measures are implemented consistently, avoiding difficult-to-find security holes.
4. Test implemented security measures
Too often, inspection and validation of security as implemented often gets overlooked. Penetration testing is a foundation for testing security and can provide valuable feedback on areas that need to be addressed. If you are running on Amazon Web Services, you may be able to use the open source Security Monkey tool that Netflix has made available. It goes through an application topology and evaluates whether its resources have implemented the organization's security measures. Many IT organizations contract with external parties to test application security measures. That's a good idea, since it provides an opportunity for impartial evaluation of application security and is likely to identify security gaps that internal personnel might overlook.
5. Migrate nonstrategic applications to external SaaS offerings
IT security teams are often overworked and under-resourced. One good way to reduce their work scope is to offload nonstrategic applications to someone else, thereby enabling them to focus their efforts on truly important applications. For example, email (a common hacker target) will almost certainly be more secure if operated by a specialist provider. Why not let it take responsibility for security?
6. Use cloud-based security products
One of the biggest impediments to good IT security practices is the lack of staff and budget to purchase and use appropriate products. SaaS-based security offerings provide two benefits: They do not require large capital investment to pay up-front license fees, and they do not necessitate IT staff to install and configure the products. Instead, IT staff can focus on configuration and use, and the lower cost of cloud-based services means security budgets go further.
7. Focus on security monitoring
The new world of next-generation applications means many more resources must be tracked and protected. Configuring security settings to generate alerts is critical; it can be a delicate balancing act to get the configuration correct so that important alerts are not hidden in a blizzard of unimportant data. This typically requires ongoing assessment and configuration updates, along with use of tools to display security anomalies and send important alerts to staff so that security issues can be addressed immediately.
It may seem as though next-generation applications impose uncomfortable change and complexity on traditional security practices. That's no doubt true, but it's also irrelevant. There is a new IT world emerging, and yesterday's approach to security is incapable of performing its duties. Only by moving to an updated approach to security can IT organizations uphold their responsibilities in a next-generation application era.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
