1. Home
  2. Training Library
  3. CISSP: Domain 3 - Security Architecture & Engineering - Module 5

Assess and mitigate vulnerabilities in web-based systems

Assess and mitigate vulnerabilities in web-based systems
Overview
Transcript
DifficultyAdvanced
Duration37m

Description

Course Description

This course is the 5th of 6 modules of within Domain 3 of the CISSP, covering security architecture and engineering

Learning Objectives

The objectives of this course are to provide you with and understanding of:

  • Common attacks against cryptography
  • How to assess and mitigate vulnerabilities in web-based systems, discussing suggested protections, XML, SAML and OWASP
  • How to assess and mitigate vulnerabilities in mobile systems, discussing risks from remote computing and risk for mobile workers

Intended Audience

This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.

Prerequisites

Any experience relating to information security would be advantageous, but not essential.  All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.

Feedback

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

About the Author

Students283
Courses13
Learning paths1

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.

 

Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.

We're moving into section nine in which we're going to assess a mitigate vulnerabilities in web-based systems. So in this particular portion of our domain three, we're going to look at suggested protections for the web, Extensible Markup Language, SAML, the Security Assertion Markup Language and we're going to look at some comments and recommendations made by OWASP, the Open Web Application Security Project People. 

Now as a beginning point, we want to suggest that having a particular assurance sign-off process for web servers is one of the very best ways to begin. This means that we have a formalized process of review, that at its conclusion as the decisions made by the parties reviewing the web, the web application, the web servers and then having reviewed the code and its processes, if only at a functional level, signing off to say that yes, it's ready to go. Part of that process leading up to the sign-off should be hardening the operating system used on such servers. 

Now, system hardening is, of course, a very commonly exercised practice but it's one that we have to exercise with especial diligence because this particular system is going to be exposed on the web as opposed to being strictly internal. Being exposed on the webs means it's going to be available worldwide most likely. So we need to take various steps to ensure that it's prepared for that. Removing default configurations and accounts, configuring permissions and passwords and privileges correctly, keeping up to date with vendor patches and of course, removing all of the stored back doors and passwords that may be embedded in it during the development cycle. And we need to extend the web and network vulnerability scans prior to deployment because once it's out there, we're going to have to do them in a live-fire kind of an environment. Better we should do it before it goes there. We want to passively assess IDS and other forms of intrusion prevention systems. 

Now, on the web, the IDS or IPS type of platform may prove to be infeasible, nonetheless, it is something that we should investigate for application. Using application proxy firewalls in the appropriate usage case. Disabling any unnecessary code libraries or better yet, removing them if they're not necessary for its operation and then making sure that administrative interfaces are removed or secured. The basic rule here should be if it's not needed for the application to function properly on the web, why have it in there. It should simply be removed. Otherwise, just because it's been inactivated doesn't mean it couldn't be reactivated or in some way exploited by attacker. 

One mistake that is frequently made and unfortunately, attackers find this to be a fairly common occurrence is the hard coding of the authentication credentials into the application itself. This is a way that we are able to very effectively shoot ourselves in the foot and so going through the final pass before an application or a web server type system gets provisioned on the web, we need to pass it through configuration control one more time to make sure that these have all been identified and removed. If we're going to use certificates, we need to be sure that the security of the credentials using these certificates are of high trust qualities. 

There should be a function that does account lock-out and supplies extended logging and audit and protects all authentication traffic with encryption. And then, as we do with all parts of any application that are going to be exposed to an unknown or untrusted network or source of users, as the internet is, we need to be sure that there is no single point of failure or weak link in this particular chain. So we need to be sure that the interface is every bit as secure as the rest of the application itself. 

We need to be sure that we have verified the input validation, functions as, and only as, its design is supposed to. And due to the fact that this again going to be available worldwide, this becomes a critical factor. We have to be sure that the application proxy firewall is able to deal with the input problems of buffer overflows, authentication issues, various forms of unwanted scripting or disallowed scripting, any form of OS or SQL command injection that will pass through to the underlying platform and then making sure that URL encoding and translation is also a feature that cannot be subverted or spoofed. 

The Extensible Markup Language specified by W3C is the standard for structuring data in a text file so that the format of the data and the data itself can be shared. Now, the markup language that accompanies this, frequently HTML, is simply a system of symbols and rules to identify structures. Now, this may seem on its face like it has very little relationship to the topic of security that we're discussing but many of the things that get subverted are in a similar state. The relationship is not necessarily obvious but by proper encoding, we strengthen the security and the resistance to subversion of all the applications and processes that we put out on the web. So we do the Security Assertion Markup Languages or SAML and this XML-based standard is used to exchange and harmonize authentication and authorization information within and across multiple systems. It is, from its outset, designed to be secure and where we find it to be used is in the federating of systems with different identity management systems so that they interact quite possibly through a simplified sign-on or even single sign-on exchanges. 

One of the mechanisms for doing this is OpenID. OpenID acts as an interoperable authentication protocol based on the OAuth 2.0 family of specifications and is finding itself very widely used in web applications. Now, the Open Web Application Security Project provides a great deal of information, generally free of charge, in the areas that you see here. They have a Top 10 Project. Like many others, they identify the top 10 attacks that succeed most frequently. They have a Project Guide, they have a Software Assurance Maturity Model called SAMM and they have a Mobile Project guide.