Web Admin Blog Real Web Admins. Real World Experience.


Completing the LASCON 2017 Badge Game

For those who don't know, every year I put together a game that starts on the back of the LASCON badge.  It's typically some combination of crypto challenges alongside application security vulnerabilities with the goal of having it take somewhere around 1-3 hours, depending on experience, to complete.  Those who complete the game are rewarded with one of these awesome challenge coins:

LASCON 2017 Challenge Coin

Now, I know that there are people out there who look at one of these things and don't even know where to start so, it is in the spirit of education and learning that I share with you my notes on how to complete the LASCON 2017 Badge Game.

Stage 1

On the back of the LASCON badge it reads as follows:

Another year, another game
Solve the puzzles, write your name
These characters aren’t a work of art
Ask a mason how to start
The key word in the text above is "mason".  If you were to Google the term "mason cipher", you would come across an interesting kind of cipher called a Pigpen/Masonic/Freemason Cipher.  The idea being that they take a geometric pattern and map the letters of the alphabet to the locations on the pattern.  Here's an example that you could use to translate this text:
Freemason Cipher
Once translated, you get the following message:
To start the badge game go to nocsal dot lascon dot org
Stage 2
When you go to nocsal.lascon.org it defaults to having a GET parameter of page=winners.php.  This is a sign that it is vulnerable to directory traversal.  There is also a comment in the page source that says “Get badge game winners from /files/winners.php”.  If you navigate to http://nocsal.lascon.org/files/, it has directory browsing enabled and you can see a test.php page there, in addition to winners.php.  If you go to http://nocsal.lascon.org/?page=test.php, you will see it grabs the test.php code and pulls it into the page source.  If you view source, you can see the text is as follows:
// Test ability to grab winners table from the database
$servername = "localhost";
$username = "lascon";
$password = "e3fmGYHDrc6MNCEMmLWj";
$dbname = "lascon";
$conn = new mysqli($servername, $username, $password, $dbname);
$sql = "SELECT * FROM lascon_winners";
$result = $conn->query($sql);
$array = $result->fetch_array();
We now have a database username and password.

Stage 3

Even though the database connection that we found uses a servername of "localhost", it turns out that mysql is open on the public IP interface of the server as well.  We can use a mysql client to connect to nocsal.lascon.org with username “lascon” and password “e3fmGYHDrc6MNCEMmLWj” (mysql -h nocsal.lascon.org -u lascon -p).  Once in the database, the user has access to read the lascon database and will see a “lascon_winners”, “users”, and “websites" table.  When you try to insert into the lascon_winners table, you quickly realize that you do not have insert permissions, so you cannot insert into the lascon_winners table.  In the users table, you see an entry with username “admin” and password “NFJXaTNuc0pyR2Y2c25iNG9Va1c=“.  In the websites table, you see a bunch of sites and one hiding amongst the others is ttpcteebhz.lascon.org.

Stage 4

When you go to http://ttpcteebhz.lascon.org in your browser, you see a form with a spot for a username and password.  You can base64 decode the string you found int he database (NFJXaTNuc0pyR2Y2c25iNG9Va1c=) to get the value “4RWi3nsJrGf6snb4oUkW”.  Once you have that, you can log in with username “admin” and password “4RWi3nsJrGf6snb4oUkW”.

Stage 5

Once logged in with the username and password, you see a blank page.  Once you view the page source, however, you see that it contains a hidden form and fields:

<form name="submission" method="post" action="">
<input type="hidden" name="first_name" value="" readonly />
<input type="hidden" name="last_name" value="" readonly />
<input type="hidden" name="phone" value="" readonly />
<input type="hidden" name="email" value="" readonly />

The last part of the challenge you could accomplish with a proxy tool, but I just used the Developer Tools in Chrome.  I changed the hidden fields to text fields, removed the readonly values, and then added a form submit button. Once submitted, the game is over and you win!

A Quick Summary of Puzzles Solved / Vulnerabilities in the Badge Game

  • Freemason Cipher
  • Directory Traversal
  • Information Disclosure in Comments
  • Directory Browsing Enabled
  • Hard-Coded Database Credentials
  • MySQL Service Publicly Accessible
  • BASE64 Encoded Passwords
  • Hidden and Read-Only Form Fields
  • Missing Form Submit Button

The OWASP Board “Ivory Tower” Dilemma

I have been an active member of the OWASP community in some form since 2007.  I've been the OWASP Austin Chapter Leader, served as the Chair of the Global Chapters Committee, and, most recently, was elected (and re-elected) to the OWASP Board of Directors.  In the past, I have heard a number of people in our community compare the Board to an "Ivory Tower".  They would say that they were unapproachable and preferred to let others do the work while they pulled the strings of the Foundation from behind the scenes.  I think there may be some truth to that statement, but I told myself when I ran for the Board that I wouldn't be like that.  I want people to feel like I am out there actively trying to solve the problems of our community.  Case in point, in my 23 months on the OWASP Board, I have proposed more Bylaw changes and new policies than anybody else.

As I continue to try to be a man of action, I find that I am often one of the first Board members on the scene in times of crisis.  On multiple occasions I've shunned the historical "Ivory Tower" approach to managing the organization and dove head in to the situation at hand.  My assumption has been that I was elected because I have an opinion, not in spite of it.  In each case I've tried to present a clear and concise analysis of my view of the situation.  I've tried to offer up suggestions on next steps or provide data points that others may not have been aware of.  Being such a diverse community has many strengths, however, one weakness is that it is difficult to drive to a consensus on anything.  It really doesn't matter what side of the issue you are on, it always seems like some will agree with you and others will not.  Frequently, what begins as an intended friendly and spirited debate, ends with somebody feeling marginalized because a decision was made that they did not agree with.  It's sad when this happens, but is inevitable when you mix passionate people with issues that do not have binary answers.

This leads me back to the "Ivory Tower" dilemma.  If my desire is to actively be a part of the community, then I place myself directly in a position of potential conflict when I speak.  I'm not allowed to speak as Josh, the community member, because the perception is that I am always speaking with my Board member hat on.  And I have a strong feeling that this perception of Board members speaking authoritatively is what leads a person on the other side to feel marginalized.  Definitely not intended, at least on my part, but that's what I've started to gather from some of the feedback that I've received.  So if that's the case, then I begin to wonder if the situation would have been better off had I held my tongue and refrained from jumping into the discussion in order to let our community continue to fight it out or to let another Board member, our Executive Director, or somebody else communicate the Board's analysis and actions.  But, if I do that, aren't I now perpetuating the stereotype of the OWASP Board being an "Ivory Tower"?

I'm not sure that there is a right or wrong answer here and nobody said that being a Board member would be easy, but I can't say that I ever expected to need to give up my personal voice with the community (the one that likely got me elected to the Board in the first place) in order to serve the Board.  That said, it genuinely saddens me when an extremely valued OWASP volunteer feels the need to leave in order to make a point.  It is a huge loss for the OWASP Foundation and one that I, regrettably, played a role in provoking.  I don't apologize for my stance on the issue that was being debated.  I feel that we should all be allowed to have an opinion and I still support the actions of the Board thus far.  That said, if I could take back my words, crawl back into that "Ivory Tower", and let someone else do the talking in this particular situation, I'm sorry to say that I would.

Johanna, I'm sorry that it turned out this way.  You may not believe it, but I sincerely respect and appreciate what you have done for the OWASP Foundation more than words can express.  You have brought order where there was chaos and a dedication to the cause that was matched only by your intellect.  I feel that we don't have to always agree on a vision in order for me to appreciate your perspective.  I regret that I never conveyed that to you before now.  I'm sorry.


My First Six Months as an OWASP Board Member

When I first put my name in the hat for the OWASP elections in the fall of 2013, I thought I knew what I was signing up for.  I thought that my seven year history with the organization in a number of different roles (Chapter Leader, Chapter Committee Chair, AppSecUSA Chair) had me well prepared for the duties of an OWASP Board member.  I told my wife that it wouldn't be a big deal, mostly something that I could do in my spare time while at work, and that it would feel good to be able to make a difference on a bigger scale than I'd done to date.  I ran for the Board on a platform of wanting to support the growth of the OWASP chapters around the world and wanting to drive visibility, and ultimately buy-in, back to the community.  I told myself that as passionate as I was with these things as a community member, it was time to either put up or shut up.

Here I am, six months later, as an elected member of the OWASP Board of Directors and I can honestly say that no prior experience could have prepared me for this.  It's not a good thing or a bad thing, it's just very different than I expected.  As a community member, I remember being at the AppSecUSA conferences and struggling with how to introduce myself to these "famous" OWASP Board Members.  I was a just a chapter leader struggling to come up with ideas to engage the Austin security community while these guys were literally trying to change the world.  They were the figurative "Rock Stars" of my little security world.  Needless to say, I see things a bit differently now, but it's probably not what you think.

When I look at my fellow Board members, I do still see those "Rock Stars".  I can't even begin to tell you how much I look up to guys like Jim Manico for literally spending every day of his life trying to make the world more secure.  I constantly have to tell myself that even though I don't consider myself a security rock star, the community saw something in me and put me on the Board for a reason and I continue to hold myself responsible for executing on the platform that I laid out in my election materials.  But what I've come to realize now, that I didn't realize before my election, is that even though it feels the other way around, it's really the community, not the Board that holds the power in OWASP.

When I look back at the discussions that we've had as a Board over the past six months, other than setting strategic goals, the vast majority of our meetings have focused on operational and governance issues.  Through this process, I have come to the realization that while extremely important to keeping OWASP, as a non-profit organization, afloat, this isn't the kind of exciting world-wide impact stuff I thought I had signed up for.  As an example, my first two months as a Board member were spent in large part re-investigating a situation that a previous Board had closed the books on long ago.  In the process of trying to help the individual involved, I was twice accused by that individual (and acquitted) of violating OWASP's Code of Ethics.  Talk about gratitude.  Since then, it seems like it's been putting out one small fire after another.  More recently, I've spent many hours working with the Board and the Executive Director to grapple with an employee who resigned from the organization only to have members of our community question whether we, as an organization, did enough to keep them here, without knowing all of the details.  It blows my mind how the Board can have unanimous support for an item, feel confident that it's in the best interest of the organization, and still be called into question as to whether we are somehow being underhanded in our decisions.  It's like we sometimes forget that the Board is made up of seven people, from all over the world, with vastly different beliefs, desires, and even visions for OWASP.  If you can get that many people, that diverse, on the same page, then there's something to be said for that.

So, I guess in a nutshell what I'm saying is that while I feel that it's quite the privilege to be serving on the OWASP Board alongside some of the people I respect most in this industry, there is definitely a part of me that feels like the stuff that OWASP does that has the most profound impact on global security isn't what we do on the Board, but rather, what the community does in our Chapters and Projects.  The Board is there to support you, the community.  To create the policies to make you successful.  To provide the staff to make your lives easier so that you can spend your time doing things that accomplish OWASP's mission.  In addition, I want to dispel any notion that the Board is some sort of an Ivory Tower.  There should never be an "us vs them" mentality at OWASP because the Board is made up of people who have been, and in many cases still are, in the trenches right alongside the community.  The Board, to put it simply, is just a group of Chapter Leaders, Project Leaders, and other members of our community who, like me, decided that it was time to put up or shut up.  People who, for whatever reason, the community elected as our leaders to evangelize the OWASP mission and make the community that we hold near and dear to our hearts successful.  To think that anyone would volunteer to be a Board member only to destroy our community is absurd.  While I may not necessarily agree with everything my fellow Board members say or do, I have never questioned their loyalty to OWASP and I hope you don't either.

With all of the above having been said, I feel that it's also important to say that being an OWASP Board member is also an amazing opportunity to be a catalyst for change.  Over the past six months the Board has stepped up to the task of driving visibility and control back to our community.  We've instituted a new polling system that the Board have used to take the pulse of the community on key issues.  Michael has taken on the responsibility of weekly calls with the community in order to keep them informed of key issues and allow them to provide feedback.  And we are currently working on bringing back the committees under a new structure that will encourage participation and empower our leaders to take action.  OWASP even won the SC Magazine Editor's Choice Award at this year's RSA Conference.  Regardless of how you've felt about OWASP in the past, I feel quite strongly that the future for OWASP is so bright we're going to need a good pair of shades.

So, I'll end this post very similar to how it began.  The OWASP Foundation is currently accepting nominations for the OWASP Board of Directors.  If you've ever felt passionate about Information Security or felt like you have big ideas to make OWASP a better community, then now is the perfect time to throw your hat into the ring as I did.  I can't promise that it'll make you a security rock star.  I can't even promise that the work is glamorous.  And my experience, thus far, has been that it's been countless hours of volunteer work with little appreciation for what gets done.  But, what I can promise, is that OWASP is making the world a better place and the Board plays a vital role in making that happen.  You, too, can be a catalyst for change.


The OWASP Security Spending Benchmarks Project

This presentation was by Boaz Belboard, the Executive Director of Information Security for Wireless Generation and the Project Leader for the OWASP Security Spending Benchmarks Project.  My notes are below:

It does cost more to produce a secure product than an insecure product.

Most people will still shop somewhere, go to a hospital, or enroll in a university after they have had a data breach.

Why do we spend on security?  How much should we be spending?

  • Security imposes extra costs on organizations
  • The "security tax" is relatively well knnown for network and IT security - 5 to 10% (years of Gartner, Forrester, and other studies)
  • No comparable data for development or web apps
  • Regualtions and contracts usually require "reasonable measures".  What does that mean?

OWASP Security Spending Benchmarks Project

  • 20 partner organizations, many contributors
  • Open process and participation
  • Raw data available to community

Reasons For Investing in Security

  • Contractual and Regulatory Compliance
  • Incident Prevention, Risk Mitigation
  • Cost of Entry
  • Competitive Advantage

Technical and Procedural Principles

  • Managed and Documented Systems
  • Business-need access
  • Minimization of sensitive data use
  • Security in Design and Development
  • Auditing and Monitoring
  • Defense in Depth

Specific Activities and Projects

  • Security Policy and Training
  • DLP-Type Systems
  • Internal Configurations Management
  • Credential Management
  • Security in Development
  • Locking down internal permissions
  • Secure Data Exchange
  • Network Security
  • Application Security Programs

OWASP Top 10 – 2010

This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member.  My notes are below:

What's Changed?

  • It's about Risks, not just vulnerabilities
    • New title is: "The Top 10 Most Critical Web Application Security Risks"
  • OWASP Top 10 Risk Rating Methodology
    • Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
  • 2 Risks Added, 2 Dropped
    • Added: A6 - Security Misconfiguration
      • Was A10 in 2004 Top 10: Insecure Configuration Management
    • Added: A8 - Unvalidated Redirects and Forwards
      • Relatively common and VERY dangerous flaw that is not well know
    • Removed: A3 - Malicious File Execution
      • Primarily a PHP flaw that is dropping in prevalence
    • Removed: A6 - Information Leakage and Improper Error Handling
      • A very prevalent flaw, that does not introduce much risk (normally)
  1. A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
  2. A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser.  For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe.  (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
  3. A3 - Broken Authentication and Session Management: Means credentials have to go with every request.  Should use SSL for everything requiring authentication.
  4. A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
  5. A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application.  Vulnerability is caused by browsers automatically including user authentication data with each request.  (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
  6. A6 - Security Misconfiguration: All through the network and platform.  Don't forget the development environment.  Think of all the places your source code goes.  All credentials should change in production.
  7. A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
  8. A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL.  If they aren't validated, attacker can send victim to a site of their choice.
  9. A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely.  Failure to identify all sensitive data.  Failure to identify all the places that this sensitive data gets stored.  Failure to properly protect this data in every location.
  10. A10 - Insufficient Transport Layer Protection

OWASP Top 10 Risk Rating Methodology

  • Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
  • Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
  • Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy),  2 (Average), 3 (Difficult))
  • Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))

This is generic across the internet, not specific to any organization.

Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).

What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.


OWASP Live CD: An open environment for Web Application Security

General Goals Going Forward

  • Showcase great OWASP projects
  • Provide the best, freely distributable application security tools/documents
  • Ensure that the tools provided are easy to use as possible
  • Continue to document how to use the tools and how the modules were created
  • Align the tools with the OWASP Testing Guide v3 to provide maximum coverage
  • Awesome training environment

330,081 total downloads as of 10/5/2009

~5,094 GB of bandwidth since launch (7/2008)

Most downloads in 1 month = 81,607 (3/2009)

Available Tools: 26 "Significant"

  • Web Scarab
  • Web Goat
  • CAL9000
  • JBroFuzz
  • WSFuzzer
  • Wapiti
  • Burp Suite
  • Paro
  • Spike Proxy
  • Rat Proxy
  • w3af
  • Grendel Scan
  • Nikto
  • nmap
  • Zenmap
  • sqlmap
  • SQL Brute
  • Metasploit
  • ....

OWASP Documents

  • Testing Guide v2 & v3
  • Top 10 for 2007
  • Top 10 for Java Enterprise Edition
  • AppSec FAQ
  • Books (CLASP, Top 10 2007, Top 10 + Testing + Legal, WebGoat and Web Scarab, Guide 2.0, Code Review)
  • WASC Threat Classification

Where are we going?

  • Project Tindy (Live CD installed to a virtual hard drive, persistence, VMware, VirtualBox, and Paralles)
  • Project Aqua Dog (OWASP Live CD on a USB drive, VM install + VM engine + USB drive = mobile app sec platform, currently testing, Qemu is the current VM engine)
  • Much easier URL - AppSecLive.org
  • Community site around OWASP Live CD
  • Online Tool DB (331+ tools)
  • New release will be based on Ubuntu instead of SLAX
  • Create .deb packages for every tool
  • Create a repository for packages
  • Add dependency info to packages
  • Brings the 26,000+ existing packages to the Live CD
  • More fun cool stuff like Wubi (install Ubuntu onto an existing windows desktop to be able to dual-boot without repartitioning windows)

Design Goals

  • Easy for users to keep updated
  • Easy for project lead to keep updated
  • Easy to produce releases (every 6 months)
    • Crank out new .debs when new tool releases
    • Continually updating repository
  • Focused on just application security - not general pen testing
    • Both dynamic and static tools
    • Developer tools also

OWASP Education Project

  • Natural ties between these projects
    • Already being used for training classes
    • Need to coordinate efforts to make sure critical pieces aren't missing form the OWASP Live CD
    • Training environment could be customized for a particular class thanks to the individual modules
      • Student gets to take the environment home
    • As more modules come online, even more potential for cross pollination
    • Builder tools/docs only expand its reach
    • Kiosk mode?

Crazy Pie in the Sky Idea

  • .deb package + auto update + categories = CD profiles
  • Allows someone to customize the OWASP Live CD to their needs
  • Example Profiles:
    • Whitebox testing
    • Blackbox testing
    • Static analysis
    • Targe specific (Java, .Net)

What have you done for me lately?

  • For Testers/QA testers
    • Wide array of tools, preconfigured and ready to go
    • Nice "jump kit" to keep in your laptop bag
    • Great platform to test or learn the tools
  • For App Sec Professionals
    • Both dynamic and static tool coverage
    • Ability to customize the job your on
  • For Trainers
    • Ready to go environment for students
    • Ability to customize for the class

Get Involved

  • Join the mailing list
  • Post on hte AppSecLive.org forums
  • Download an ISO or VM
    • Complain or praise, suggest improvements
    • Submit a bug to the Google Code site
  • Create a deb package of a tool
    • How I create the debs will be documented, command by command and I'll answer questions gladly
  • Suggest missing tools, docs, or links
  • Do a screencast of one of the tools being used on the OWASP Live CD

Learn More

  • Google "OWASP Live CD"
  • Download & Community Site (http://AppSecLive.org)

Everything is stored in /opt/owasp

Tagged as: , , , No Comments

The ESAPI Web Application Firewall

This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project.  My notes are below:

WAF Fallacies (at least in regards to OWASP ESAPI WAF)

  • WAFs add attack surface
  • WAFs can create culture problems
  • WAFs can't fix business logic vulnerabilities
  • WAFs are way too expensive
  • WAFs complicate networks

Why fix in ESAPI WAF vs Fix in code?

  • Changing in ESAPI WAF is just a text file
  • Shorter gap between time discovered and WAF fix vs code fix

Advantages of WAF

  • Performance - Only your rules are checked, plus state is already managed by the app server
  • Capability - being closer to the app lets us do more
  • Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time

Principle: Make common tasks easy, uncommon tasks possible

General virtual patching functionality is easy to understand

Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy

Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)

Can add "outbound" security as well

  • Add anti-clickjacking header
  • Set uniform content-type
  • Add HttpOnly flag
  • Add secure flag
  • Detect outbound information
  • Replace outbound information

Takes advantage of early failing to make rules as optimized as possible

Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):

  • Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
  • Unchecked Redirect
  • Add HttpOnly
  • Add anti-clickjacking header
  • Privilege escalation

3 Different WAF Modes

  • Log
  • Block
  • Redirect

Latency with all of the rules turned on is about 5%.  With selected rules is closer to 0%.  Basically an order of n magnitude where n is the number of rules enabled.  Comes out to milliseconds.


Software Assurance Maturity Model (SAMM)

This presentation on the OWASP Software Assurance Maturity Model (SAMM) was by Pravir Chandra, the project lead.  I was actually really excited in seeing this topic on the schedule as SAMM is something that I've been toying with for my organization for a while.  It's actually a very simple and intuitive approach to how to assess where your organization is at as far as software maturity, where you want to get to, and how to get there.  My notes on this presentation are below:

By the end of the presentation should be able to....

  • Evaluate an organizations existing software security practices
  • Build a balanced software security assurance program in well-defined iterations
  • Demonstrate concrete improvements to a security assessment program
  • Define and measure security-related activities throughout the organization

Lessons Learned

  • Microsoft SDL
    • Heavyweight, good for large ISVs
  • Touchpoints
    • High-level, not enough details to execute against
    • Large collection of activities, but no priority ordering
  • ALL: Good for experts to use as a guide, but hard for non-security folkds to use off the shelf

Drivers for a Maturity Model

  • An organization's behavior changes slowly over time
    • Changes must be iterative while working toward long-term goals
  • There is no single recipe that works for all organizations
    • A solution must enable risk-based choices tailored to the organization
  • Guidance related to security activities must be prescriptive
    • A solution must provide enough details for non-security-people
  • Overall, must be simple, well-defined, and measurable

Therefore, a viable model must...

  • Define building blocks for an assurance program
    • Delineate all functions within an organization that could be improved over time
  • Define how building blocks should be combined
    • Make creating change in iterations a no-brainer

SAMM Business Functions (4 in total)

  • Start with the core activities tied to any organization performing software development
  • Named generically, but should resonate with any developer or manager
  • Governance, Construction, Verification, Deployment

SAMM Security Practices (12 in total)

  • From each of the Business Functions, 3 Security Practices are defined
  • The Security Practices cover all areas relevant to software security assurance
  • Each one is a 'silo' for improvement
  • Governance: Strategy & Metrics, Education & Guidance, Policy & Compliance
  • Construction: Threat Assessment, Security Requirements, Secure Architecture
  • Verification: Design Review, Code Review, Security Testing
  • Deployment: Vulnerability Management, Environment Hardening, Operational Enablement

What is "software"?

  • Lots of different aspects of what software is
  • Could be a tarball of source code, UML and specifications, or a server running the code

Under each Security Practice

  • Three successive Objectives under each Practice define how it can be improved over time
  • Level 1, Level 2, and Level 3
  • "Going from crawling to walking to running"
  • 72 different actives all about the size of a bread box

Per Level, SAMM defines...

  • Objectives
  • Activites
  • Results
  • Success Metrics (2-4 metrics for each objective)
  • Costs (training, content, license, or buildout)
  • Personnel (overhead on different roles because operating at this level)

Conducting Assessments

  • SAMM includes assessment worksheets for each Security Practice

Assessment Process

  • Supports both lightweight and detailed assessments
  • Organizations may fall in between levels (+)

Creating Scorecards

  • Gap Analysis
    • Capturing scores from detailed assessments versus expected performance levels
  • Demonstrating Improvement
    • Capturing scores from before and after an iteration of assurance program buld-out
  • Ongoing Measurement
    • Capturing scores over consistent tiem frames for an assurance program that is already in place

Roadmap Templates

  • To make the "building blocks" usable, SAMM defines Roadmaps templates for typical kinds of organizations
    • Independent SW Vendors
    • Online Service Providers
    • Financial Services Organizations
    • Government Organizations
  • Organization types chose because
    • They represent common use-cases
    • Each organization has variations in typical software-induced risk
    • Optimal creation of an assurance program is different for each

Expert Contributions

  • Build based on collected experiences with 100's of organizations
    • Including security experts, developers, architects, development managers, IT managers

Industry Support

  • Several case studies already
  • Several more case studies underway

The OpenSAMM Project

  • http://www.opensamm.org
  • Dedicated to defining, improving, and testing the SAMM framework
  • Always vendor-neutral, but lots of industry participation
  • Targeting new releases every ~18 months
  • Change management process

Future Plans

  • Mappings to existing standards and regulations
  • Additional roadmaps where need is identified
  • Additional case studies

All About OWASP

The second presentation of the morning was various members of the OWASP board speaking about the goals of OWASP for the upcoming year.  My summary is below.

Jeff Williams

  • Cross Site Scripting is an epidemic
  • We need to view insecure software as a disgrace
  • Everything OWASP is free and void of commercialism
  • "When information comes with an agenda, people discount it"

Tom Brenan

Global Membership Committe 2010 Focus

  • Global expansion
  • 7x increase (2008)
  • Vote your board members

Global Industry Committee 2010 Focus

  • Building industry special interest groups
  • Continuing to impact regulation (NIST, government, organizations, EU)

Dave Wichers

Global Conferences Committee 2010 Focus

  • Support four global AppSec Conferences per year
  • Support OWASP regional and local events worldwide

Sebastian Deleersnyder

Global Education Committee 2010 Focus

  • Academic outreach
  • OWASP bootcamp
  • Roll out college OWASP education kits

Global Chapter Committee 2010 Focus

  • Identify and reactive inactive chapters
  • Actively support chapters with mentors and speakers
  • College OWASP education kits

Dinis Cruz

Global Projects Committee 2010 Focus

  • Apply assessment criteria version 2 to all projects
  • Unified dashboard for OWASP projects
  • Launch and manage 2010 season of code
Tagged as: , , , No Comments

Using Proxies to Secure Applications and More

I've been really surprised that for as long as I've been active with OWASP, I've never seen a proxy presentation.  After all, they are hugely beneficial in doing web application penetration testing and they're really not that difficult to use.  Take TamperData for example.  It's just a firefox plugin, but it does header, cookie, get, and post manipulation just as well as WebScarab.  Or Google Ratproxy, which works in the background while you browse around QA'ing your web site and gives you a nice actionable report when you're done.  I decided it was time to educate my peers on the awesomeness of proxies.

This past Tuesday I presented to a crowd of about 35 people at the Austin OWASP Meeting.  The title of my presentation was "Using Proxies to Secure Applications and More".  Since so many people came up to me afterward telling me what a great presentation it was and how they learned something they can take back to the office, I decided (with a little insistance from Ernest) that it was worth putting up on SlideShare and posting to the Web Admin Blog.

The presentation starts off with a brief description of what a proxy is.  Then, I talked about the different types of proxies.  Then, the bulk of the presentation was just me giving examples and demonstrating the various proxies.  I included anonymizing proxies, reverse proxies, and intercepting proxies.  While my slides can't substitue for the actual demo, I did try to include in them what tool I used for the demo.  If you have any specific questions, please let me know.  All that said, here's the presentation.