Jason Yuen - "Understanding Information Security"

Top Web 2.0 Security Threats

2009-03-19T19:20:00.004-04:00

Web 2.0 has changed the landscape of Web Application Security. As the general public, corporations, and even Government continue to use Web 2.0 sites, new threats and vulnerabilities will continue to emerge.

Web 2.0 has increased the attack surface; good for hackers, bad for security professionals. Secure Enterprise 2.0 Forum has compiled a list of the "Top Web 2.0 Security Threats" which can be found here.

1. Cross Site Scripting (XSS)
2. Cross Site Request Forgery (CSRF)
3. Phishing
4. Information Leakage
5. Injection Flaws
6. Information Integrity
7. Insufficient Anti-Automation

Building Security In Maturity Model (BSIMM) v1.0 Released

2009-03-12T21:59:00.004-04:00

"Properly used, BSIMM can help you determine where your organization stands with respect to real-world software security initiatives and what steps can be taken to make your approach more effective. BSIMM is not a complete 'how to' guide for software security, nor is it a one size fits all model. Instead, BSIMM is a collection of good ideas and activities that are in use today."

BSIMM by Cigital and Fortify

Software security requires a multifaceted approach and a practical plan to reach a certain level of maturity. BSIMM aids organizations in developing their own software security roadmap. As security practitioners, our goal is to constantly strive for improvement in security processes and methodologies to effectively defend against the constant evolution of threats and vulnerabilities.

Want to Play Poker? ... Protection Poker: A New Practice to Secure Application Development

2009-02-24T21:07:00.004-05:00

Researchers at NC State have developed a new innovative practice called Protection Poker. This interactive tabletop process allows Developers, Security Experts, Upper Management, and other various key stakeholders to perform threat modeling without the burden of discussing code implementation. The process would be executed prior to development and most likely after draft requirements have been defined. It would allow for additional changes to the RTM, if needed.

"The dual purpose of a Protection Poker session is (1) to structure a collaborative, interactive, and informal practice for misuse case development and threat modeling; and (2) to spread software security knowledge throughout a team."

More information can be found here:
Poker: The New Game in Secure Application Development
Protection Poker: Structuring Software Security Risk Assessment and Knowledge Transfer

WAS 2.0 - Are you ready?

2009-02-12T09:48:00.025-05:00

Web 2.0 technologies are gaining more and more attention as each day passes. It is all over the Internet and even beginning to enter the Government space. How does it affect us?

Well, Web 2.0 offers a more enjoyable Web experience through enhanced collaboration, information sharing, and user functionality. This comes with a cost and additional security risks to the organization and end users. Securing Web 2.0 is usually an afterthought; mainly because security impedes the focus of being user-friendly and innovative. Currently, Web 2.0 security is not nearly as strong as Web 1.0. We are just getting up to speed on implementing Web 1.0 security controls. Introducing a new set of variables will increase the complexity of Web Applications. We're not ready!

Web Application Security 2.0 (WAS 2.0) will be more common in the upcoming year as the focus will shift more in the direction of Web 2.0. You may have already heard the term "Government 2.0". GSA has already launched new Web 2.0 tools for USA.gov with many Departments/Agencies following in their footsteps. President Obama has embraced Web 2.0 during his campaign and will continue to do so throughout his administration. The "Change" that is about to come will be a drastic overhaul of legacy Government systems, but does cyber security play as big of a role as President Obama originally pitched?

Here are just a few basic Web 2.0 security risks among the many possibilities and examples of Government 2.0 Security Incidents/Vulnerabilities ...
Top 10 Web 2.0 Attack Vectors
President Obama's Campaign w/ a Trojan Horse
Government and Twitter + Twitter Hacked
Congressman uses Twitter and Reveals "Secret" Location

Web Application Security - Part 2: How to Define Security Requirements

2009-02-09T19:17:00.004-05:00

In most organizations today, a detailed framework for defining security requirements does not exist. Typically, NIST SP 800-53 is translated and defined as the high-level security requirements and standards for use in the development of an application or system.

There is a gap between the standards listed in NIST SP 800-53 and the actual defined requirements being tracked throughout the SDLC. Usually all security requirements are thrown into a bucket that is on a separate page from the rest. This may be logical, but what happens? It may be forgotten. It may not be integrated into current development of other functions. It is not a top priority and may end up being satisfied retroactively. What should happen? Security requirements should be integrated with other requirements where it fits with that particular function or component.

A framework for translating NIST standards into detailed traceable security requirements needs to be adapted for every project. Security best practices, developer security methods and techniques, and additional countermeasures can all be combined and tailored to fit organizational needs for a holistic security approach. This framework should be written in such a way that all teams (Security, Development, QA, etc.) can understand the security requirements to be able to translate them into their own activities. A Security Requirements Framework (SRF) is a more effective tool for integrating traceable security requirements and best practices into the SDLC.

QA and Security "Testing" ... a Logical Combination

2009-02-04T19:16:00.002-05:00

As stated in my previous post, security "testing" fits into Quality Assurance. This a hot topic and is discussed again here. This is the final gate that applications need to successfully pass in order to be considered for deployment. This sort of "testing" is not going to be thorough; especially if QA lacks security expertise. So how do we solve this problem?

Simple. Develop test plans and specific test cases that can be executed by QA Team members. It reduces the amount of work of the Security Team with the bulk of it done by QA. It will also serve as an indicator of security posture. If a security defect is found, the Security Team can be alerted for further analysis. This Security Review is a perfect way to enhance Web Application Security.

Effective security testing is important, but resources may be limited. Test plans and test cases are the bread and butter of the QA Team, so it makes sense.

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

2009-01-30T07:51:00.004-05:00

"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?

2009-01-22T21:38:00.001-05:00

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

2009-01-21T19:21:00.002-05:00

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?

2009-01-20T18:41:00.002-05:00

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.