Protect your applications to make Enterprise Security matter


Security is like a game of Chess

Security is like a game of Chess

Enterprise Security is like playing the game of Chess. Adversaries on the prowl aim to take possession of the most valuable asset in your Enterprise – just like the all-powerful Queen in Chess. They try to penetrate the perimeters of the enterprise through the demilitarized zones, the intranet, the servers, the operating systems, the applications and finally, the data. Their goal is to gain access to the underlying data, which has even more value and context as information when accessed through the applications layer. While a defense in depth strategy through multiple layers of protection is important, it is vital that the applications layer is protected to make security matter in your enterprise.

Applying Security across the SDLC

So, what steps can enterprises take to protect their applications – the weakest link in Enterprise Security? The “Application security in the SDLC” session by Kevin Poniatowski from Safelight Security at HP Protect 2013 provides some pointers. “Application security is a process that must be included in all phases of the development lifecycle to mitigate risk,” Poniatowski writes. What exactly does this mean within each phase of the Software Development Life Cycle (SDLC)?

  1. Analysis. Along with functional requirements, the non-functional requirements—including security—must also be determined for an application before it is architected. This includes a gap analysis of security regulations and best practices that apply to individual applications. Doing so would make it easier to justify the cost of enforcing the right security measures in alignment with these requirements.
  2. Architecture. Security is an integral part of the Enterprise Architecture (EA) DNA. High-level view of the architecture for threat modeling and attack surface analysis must be used to identify weaknesses in the structure and design, which correlate directly into security vulnerabilities that are likely to be coded or configured into an application.
  3. Build. Application designs must also address the not-so-happy what-if scenarios as well. Model-driven approaches work well to proactively anticipate security violations, ensuring the right measures are in place at design time. Tools must be used to effectively scan the source code for vulnerabilities. Have you checked out Nadhan’s law of Secure Applications?
  4. Test. “You can’t rely only on testing scenarios to find and fix all of your existing application vulnerabilities,” Diamant cautions. We must still test and fix security flaws even though they are reactive measures that should have been preempted in the preceding phases.
  5. Sustain. Applications meet infrastructural components of network and storage, which open up additional intersection points — a fertile ground for violations. Independent validations and verifications of existing applications must be performed to proactively identify gaps, and therefore vulnerabilities.

The 9th Annual HP Security user conference, HP Protect 2013 provides an opportunity to attend about 150 technical sessions on Enterprise security that comprehensively addresses various aspects including Network, Data, Software and Information and Event Management.

What measures are you taking within your enterprise to proactively enforce application security across the Software Development Life Cycle (SDLC)? Please consider attending the Application security session to check out other options.

Team up with HP Technology Expert, E.G.Nadhan

Connect with Nadhan on: Twitter, Facebook, Linkedin and Journey Blog.

«

Leave a Reply

Your email address will not be published. Required fields are marked *