Web Application Security - Part 1: Budget is Low ... Not Enough Resources?

"We don't have enough resources!" This phrase is heard more often than none to all managers. The better question is "Why do we need more?" Is it because of performance issues? Too much work? Inefficient processes? Well it depends ... lets examine the case presented by Michael Shema from NT Objectives (here).

In many organizations today, the budget for Security Teams is always lower than the rest. Mainly because management is unaware of the consequences or impacts related to unsecured applications or maybe it is just not a top priority. The bottom line with development shops is to create the application and get it out the door to the client. But what about security??? We'll do the best we can but I guess that is all we can do.

This usually involves security testing towards the end of the SDLC and maybe some remediation of the findings if there is enough time. More likely, these slip and the product is delivered with flaws that remain undiscovered. Lack of budget, is this the real issue?

The QA Team should be tasked with finding security issues. This is the ideal case, but they lack security expertise and time to complete normal testing. The Security Team should do it then among the many other things they are responsible for. When the Security Team finds the vulnerabilities, they need the Development Team to implement the fixes. Often times, the Development Team has moved onto a new project and is not really interested or has the resources to fix old problems. "We don't have enough resources!" But it needs to be done.

Endless cycle continues. More work. More work. More work. Lack of resources will always be a problem with a Defensive Approach.

What should we do? Streamline and integrate security processes into the SDLC! Keep the Security Team involved throughout development. Include a Security Design Review to address weaknesses and design flaws. It is easier said than done and unique to every organization. In this series, I will outline ideas and best practices that can be custom-fitted to your organization.

Does IT Security Matter?

The truth is...it is really up to you. Does ___ matter? Only if you believe in it.

A presentation by Dr. Luke O'Connor brings an interesting concept to the table (full presentation here). IT Security is essential only where it is needed and applicable to business processes. The problem all information security professionals face is defining what is necessary to protect information assets based on business needs.

A majority of the time, it is based on compliance with federal mandates. However, does the application or system truly need that level of enhanced security? This is a common mistake. Does upper management know what they need? Are they aware of what they don't need? In most cases, I would say upper management rely heavily on the infosec staff. Resources are often wasted with infosec staff focusing on items that are not prioritized appropriately. What is deemed to be critical is not always the case...

IT Security is another line item that most managers cut back on. Concepts are not that difficult, but the level of effort can be substantial. Documentation bogs down security processes such as Certification and Accreditation (C&A). The end goal - to secure business processes to support the mission. Implementation of security controls is more important than 100% comprehensive documentation.

How do we resolve these issues? Define what is mission critical and develop objectives to meet specific goals. Budget for what has to be done to ensure business processes are adequately secured. "Focus on securing business processes, not the process of securing"

I'm not saying documentation should not be developed. It just isn;t as high of a priority as proper implementation itself. Look for FISMA 2.0 to shape things up in the Federal Sector.

Evolution - Essential for Innovation and CHANGE

Survival of the fittest ... in security, not really. The weak still survive.

Is it that surprising? In the private sector, companies have R&D departments for continued innovation. In the government sector, agencies rely on the private sector. It is more stagnant and innovation is lacking.

Agencies lacking strong information security such as the IRS have findings piled up over many years and has not changed. The "catch-up" game has long been a problem of the government. Commercial banks have stronger security than some government agencies. This is not surprising at all. If a bank's security was weak, it would not survive. So why do agencies survive?

Obviously it is a critical component serving a purpose that is mission critical. But it should evolve and improve! In any industry or entity, evolution is what causes innovation and change. Technologies, concepts, processes, standards, etc. all evolve and change for continuous improvement.

Today's best security practices are a direct result of being proactive. This approach should be applied to everything security-related.

Builders and Breakers?

In recent infosec news, there is some buzz referring to the term "Builders and Breakers". Builders are the developers that build applications. Breakers are the hackers that break applications.

In today's industry, the focus of information security in almost all organizations is "Breaking". Information Security Professionals are usually asked to hack applications rather than participate in designing/developing secure applications. The question remains...why not build securely?

The best way is to BUILD securely. Strong applications are those that integrate security into the SDLC at each phase with a focus on BUILDING secure applications.