This course covers section one of CSSLP Domain Four: Common Software Vulnerabilities and Countermeasures. You'll learn the elements, ideas, concepts, and principles about what issues must be considered before embarking on a building program of secure software.
- Understand programming fundamentals
- Become familiar with different development methodologies
- Learn about common software attacks and the means of exploitation
This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.
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.
So as we move on, let's take a look at attack types and variance, starting with injection style. Now injection style attacks are one of the oldest and sadly still one of the most prevalent types. So let's cover what we mean by an injection. In this form of an attack, an attacker supplies an untrusted input to a program. In other words, we're injecting it into the program execution stream. Processed by interpreter as part of the commander query. And the result is a changed in the value injected into it alters the execution of that program. And several of the most common forms, cross-site scripting, which can result in spoofing arbitrary execution or defacement as well as others, OS command injection. This can result in full system compromise given the nature of the injection type.
A SQL command injection, which can bypass authentication, produce a denial of service, result in a breach, or full control of a target system. LDPA would again do authentication bypass and privilege escalation. Email header is great for doing spam relay and disclosure sensitive information. Any form of code injection could result in full system compromise. A simple sounding one, the carriage return line feed can result in a cross-site scripting attack, which can result in other things in a secondary way. And then the path through reversal can result in information disclosure and authentication bypass. We also have a family of encryption failures and these, obviously, can result in protection failures. We have various types of this beginning with hard-coded credentials, typically considered to be a very bad idea.
Now, hard-coded credentials work as coded every time they're executed, but they can be very difficult if not impossible to change. And crypto systems themselves have operational instructions for regular updates, regular key changes, and other sorts of rotational types exercises to keep them secure. But they can also be readily discovered by reverse engineering, a tactic that hackers frequently use. There can, of course, be the missing encryption for sensitive data. This is a well known approach that reflects the fact that sensitive information, of course, requires encryption for proper protection when at rest or in motion. And it is often lacking because the definition, however, leaves unanswered what information is sensitive.
This of course, places it on the shoulders of the developer or the user of the application and the application of the encryption to protect what they define as sensitive. Now, the use of questionable cryptographic components. This reflects a couple of different problems that are continuously arising. One being home-grown crypto. Now, home-grown crypto isn't approved or certified by anybody except those who choose to employ it. This, of course, means that it's not tested widely or officially, and what tends to happen is it fails when it's attacked by intense power due to the uninformed design that typically produces it. Likewise, older algorithms are often overwhelmed by attacks that may not have been envisioned when they were new such as we experience with DES and is replacement Triple DES.
Another problem with crypto is a flawed implementation can spoil very strong encryption that might otherwise work perfectly. This is what happened with WEP, the wired equivalent privacy and it negated the strength that is still inherent in the algorithm, RC4 that was at its core. So this reflect the need to design well and choose wisely for the components. Another cryptographic failure would be a download of a code or a code segment without any integrity validation. Now, this should be done to make sure that the code is authentic and unmodified, and that there are no unwanted malware attachments or embedded code segments. Using unsalted hashes. This adds trailing values to data strings such as passwords and by doing so increases both the length and the randomness of the product. The use of an unsalted hash makes breaking data-protecting passwords far easier.
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.