Friday, February 8th, 2013.  11:00 - 12:00 ET 

• @Jérôme LELEU

• @Parker Neff (Deactivated)

• @David Ohsie

• @Andrew Petro

• @William G. Thompson, Jr.

• CAS AppSec

• Introductions

• Security Issues

• Coordinate/Collaborate

• Deliverables and other activities

After introductions, the group discussed potential contributions to the CAS project in the area of application security.  These included:

• CAS security assessment
  
  

  • Threat modeling

  • Dynamic "live" scans

  • Static code scans

• WAF for CAS

• Vulnerability report analysis

• Monitoring of 3rd party dependency vulnerabilities

• Maintaining and executing vulnerability notification process

A CAS security assessment would increase our confidence in the security of CAS and could highlight areas for improvement or exploration.  The goal would be to have a set of artifacts that provide verifiable and repeatable analysis that evolve over time hand-in-hand with CAS releases.  There are a variety to tools both comercial and open source that could provide value in this effort. 

There was a discussion regarding relying on appropriate frameworks/libraries for non-CAS protocol related functionality, such as SAML, in order to improve CAS server security posture.

• List potential tools for use in a security assessment - Team

• Reach out to potential tool vendors regarding licenses for open source projects - Bill

• Sketch out CAS security assessment - Team

• Establish liaison with Jasig Security Contact Group - Andrew

• Establish recurring meeting - Bill  

  • Vote on Doodle for time – 
    http://doodle.com/2d32akzd995ye8nt

• Assuming all code will have flaws that can be exploited, one can greatly reduce the Threat's access by only allowing within-spec data to come into the system, and dumping all the rest.

• Input validation is critical to security.  CAS itself could filter all incoming data or another tool.  Data must fit within spec's (length, content, characters allowed, etc.)  Large threat present from incoming data (from mostly untrusted, unknown sources) that can cause buffer overflows, execute code, etc.

• All data once it becomes cleartext (no longer https) must be routed to known, trusted, and hardened elements; no other elements can be allowed to handle it.  (Pre-req for input validation)