Parsons Software Security Consulting Blog

Apple: $10B In App Store Sales In 2013, $15B Paid Out To Developers To Date

leave a comment »

Written by mparsons1980

February 12, 2014 at 1:53 am

Posted in Uncategorized

The Dash Builds Wearable Fitness Sensors Into The Headphones You’re Using Anyway

leave a comment »

Written by mparsons1980

February 12, 2014 at 1:51 am

Posted in Uncategorized

Official (ISC2) Guide to the CSSLP book review

leave a comment »

Book Title  Official (ISC2) Guide to the CSSLP  
Author  Mano Paul, CSSLP, CISSP  
Publisher  CRC Press Taylor and Francis Group an Auerbach Book   
Publication Year  2011  
ISBN  13-978-1-4398-2006-5(ebook PDF)  
Number Of Chapters seven  
Number Of Pages 521  
Book Price 47.94  
Rate Content Awesome resource  
Review (

I enjoyed reading the Official Guide to the CSSLP.   I read it cover to cover and with the practice questions and the CSSLP practice questions I feel adequately prepared for the CSSLP exam I am taking in a few months.   I liked the fact that Michael Howard wrote the foreword.   He is considered one of the pioneers in the application security space. I have read many of his books and blog posts cover to cover.  
A few of my peers in the industry wrote essays to get their CSSLP.  I have my CISSP after taking the exam and having the necessary work experience.   I enjoyed the layout of The Official Guide to the CSSLP book because it covers all of the domains for the CSSLP.   I really enjoyed the real life examples in the book.  You can tell that the author has a lot of real world experience and did a lot of research to write this book.   I noticed on Amazon the author wrote an updated version of the Official Guide to the CSSLP. I may purchase that one as well. It was 20 dollars more than the one I have.   This book provides the foundation for a solid application security engineer by covering the topics of; secure software, secure software requirements, secure software design, secure implementation, coding, secure software testing, software acceptance and finally software deployment, operations and disposal.    The final chapter was most beneficial to me because I have the least experience in it.  I enjoyed secure software testing but much of it was content I was already aware of being an ethical application penetration tester.   
I like that ISC2 is creating this certification as it validates the experience and credentials of application security engineers like me.   I really, really enjoyed the diagrams in the book.  They were easy to read and allowed me to visually look at the content.   The core concepts of confidentiality, integrity and availability are drilled in this book.   My only complaint that there appears to be some duplicate content with stressing the confidentiality, integrity and availability of software systems.  
The reference to all of the standards including, industry, government, international and national standards was beneficial.   You find that many of the standards have similar goals of keeping with the confidentiality, integrity and availability of software applications.   The only issue I have with these is that I am having a hard time remember some of the different NIST certifications, as they are only a small difference in numbering.  I hope that with flash cards that I create from the content of the book I can adequately remember the content and be able to pass the exam. 
I was thrilled that Open Web Application Security Project was mentioned multiple times in the book.   I have been a long time member and have read many of the documents created by OWASP.   I am also a board member of OWASP Dallas and enjoy the mission and vision of OWASP making applications more secure around the world.  
I really enjoyed the review questions in this book.   I imagine the new book has more updated review questions.  I may have to buy that book just to get the new questions for the exam.   The author has lot of expertise in software security and put a lot of hard work into the book.   



Matt Parsons, CISSP, MSM


Written by mparsons1980

February 10, 2014 at 6:59 pm

Posted in Uncategorized

Java and .NET security

leave a comment »

Java Security

Java has many built in security features that developers of your organization need to use.   It is best not to build your own cryptography methods but use well established classes that have been tested and verified.

Java is has many built in security mechanisms that other languages do not including the following:

1.     Strong data typing

2.     Automatic memory management

3.     Bytecode verification


·       Comprehensive API with support for a wide range of cryptographic services including digital signatures, message digests, ciphers (symmetric, asymmetric, stream & block), message authentication codes, key generators and key factories

·       Support for a wide range of standard algorithms including RSA, DSA, AES, Triple DES, SHA, PKCS#5, RC2, and RC4.

Authentication and Access Control

·       Abstract authentication APIs that can incorporate a wide range of login mechanisms through a pluggable architecture

·       A comprehensive policy and permissions API that allows the developer to create and administer applications requiring fine-grained access to security-sensitive resources.


Secure Communications

APIs and implementations for the following standards-based secure communications protocols: Transport Layer Security (TLS), Secure Sockets Layer (SSL), Kerberos (accessible through GSS-API), and the Simple Authentication and Security Layer (SASL). Full support for HTTPS over SSL/TLS is also included.

Public Key Infrastructure

Tools for managing keys and certificates and comprehensive, abstract APIs with support for the following features and algorithms:

·       Certificates and Certificate Revocation Lists (CRLs): X.509

Certification Path Validators and Builders: PKIX (RFC

·       Certificates and Certificate Revocation Lists (CRLs): X.509

·       Certification Path Validators and Builders: PKIX (RFC 3280), On-line Certificate Status Protocol (OCSP)

·       KeyStores: PKCS#11, PKCS#12

Certificate Stores (Repositories): LDAP, java.util.Collection
Class SecureRandom

java.lang.Object   java.util.Random 

All Implemented Interfaces:


public class SecureRandom
extends Random

This class provides a cryptographically strong random number generator (RNG).

A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1. Additionally, SecureRandom must produce non-deterministic output. Therefore any seed material passed to a SecureRandom object must be unpredictable, and all SecureRandom output sequences must be cryptographically strong, as described in RFC 1750: Randomness Recommendations for Security.

A caller obtains a SecureRandom instance via the no-argument constructor or one of the getInstance methods:

      SecureRandom random = new SecureRandom();  

Many SecureRandom implementations are in the form of a pseudo-random number generator (PRNG), which means they use a deterministic algorithm to produce a pseudo-random sequence from a true random seed. Other implementations may produce true random numbers, and yet others may use a combination of both techniques.

Typical callers of SecureRandom invoke the following methods to retrieve random bytes:

      SecureRandom random = new SecureRandom();       byte bytes[] = new byte[20];       random.nextBytes(bytes);  

Callers may also invoke the generateSeed method to generate a given number of seed bytes (to seed other random number generators, for example):

      byte seed[] = random.generateSeed(20);

.NET security

            For the .NET portion of the article most of the security vulnerabilities come from insecure configuration management in the web.config file.

The below setting is insecure.  

      <customErrors mode="Off">

This one is secure.  

      <customErrors mode="RemoteOnly">

It is a good idea to have a custom error page that states there was a problem please try again and have the user use the back button on the users browser.

Cookies Accessible Through Client-Side Script
In Internet Explorer 6.0, Microsoft introduced a new cookie property called HttpOnly. While you can set the property programmatically, you can set it generically in the site configuration.


      <httpCookies httpOnlyCookies="false">


      <httpCookies httpOnlyCookies="true">

Custom Errors Disabled
When you disable custom errors as shown below, ASP.NET provides a detailed error message to clients by default.

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’

([Microsoft][ODBC Microsoft Access Driver] Extra )

In query expression ‘UserID=’’’ AND Password =‘’

/_tblemployees/login3.asp, line 49


      <customErrors mode="Off">


      <customErrors mode="RemoteOnly">

Having the detailed error message to the user or attacker could give an attacker information leakage about the system to launch an attack on the application.  Displaying the type of language the application is written in, the database type, the web server operating system gives too much information to a would be attacker to compromise the application.   

 Hardcoded Credentials Used

Hardcoded credentials to a production database are really the keys to sensitive intellectual property or customer data.   Anyone that has access to hard coded credentials has access to the database.  


      <password = rootpassword >


      <authentication mode="Forms">

 So hopefully you have a better understanding of java and .NET security.  A few configuration issues fixed in the web.config can make your application secure and better protect it from hackers.

Matt Parsons, CISSP, MSM

Written by mparsons1980

February 7, 2014 at 8:33 pm

Secure Coding

with one comment

With 95 percent of Web applications having software security vulnerabilities secure coding has never been more important.

With 95 percent of Web applications having software security vulnerabilities secure coding has never been more important. 80 percent of all web application have cross-site scripting vulnerabilities on them and 62 percent have more dangerous SQL injection vulnerabilities. If organizations follow simple secure coding practices a majority of these vulnerabilities can be eliminated.
With these vulnerabilities eliminated; the attack surface of your organization is greatly diminished ensuring the confidentiality, integrity and availability of your business critical web applications.
This article will talk about high-level application security concepts, Java security, .NET security, and web application security vulnerabilities and remediation steps.
Secure coding has to be implemented early in the software development process to ensure the application is secure and free from most vulnerabilities. Security is based on the remediation of design flaws and bug flaws.
Bug flaws are the Cross Site Scripting vulnerabilities and SQL injection vulnerabilities were design flaws are the improper use of authorization and cryptography to protect a web application. Both bugs and design flaws must be remediated to have a secure application.
Secure coding starts with senior management implementing a secure coding culture and giving developers the time and the tools to remediate software security vulnerabilities. Education is always important. A developer must be taught to write secure code in order for your application to be secure. Lunch and learns and training help. Online training is a good way to train many developers the basic concepts of secure coding. Individual specialized training is great to teach developers beyond the basics and the secure coding concepts in the language that they program.

In the above figure it is a good idea to have defense in depth in order to protect the business critical application.

A short checklist of what developers’ should and should not do in beneficial in remediating software security vulnerabilities. An example of this would be that all developers must validate all input and use parameterized queries. A not requirement would be that all developers cannot use MD5 hashing to protect sensitive credentials. Instead they should use something stronger as SHA-256. Telling the developers what they should and shouldn’t do is only beneficial if you show that what could and will eventually happen if they do not follow secure coding policies. A good checklist is as follows:

1. Where is the application? Where does it reside?
2. Who uses the application? What is the use case scenario?
3. Who are the attackers?
4. What does the application do?
5. What are the vulnerabilities in the application?
6. Implement policies that are already being used BSIMM.
7. Use automated review for large applications.
8. Create a secure coding check list.

With training secure coding should be implemented early in the development process whether you are using traditional waterfall methods or agile methods. Implementing security in the requirements and design phase is much more effective than bolting security on once the product is released.
SD3 is important to follow. Secure by design, secure by default and secure by deployment. Following SD3 ensures a holistic approach to application security. Having security best practices like running production applications with least privilege and using white list regular expressions for validation is also helpful. In order to reduce the attack surface of the application it is necessary to only use services that your application requires. The server administrators must turn everything else off. Too often applications are attacked by insecure unused services.
If there is only one aspect of secure coding that needed to be remembered it would be not trusting input and validating all input. This is important whether the input is coming from a user or a system in your web application. User input must be sanitized and checked with length checks, range checks and format checks. It is necessary to use defense in depth and learn from mistakes when attacks happen. Manually reviewing source code with peer code reviews and static code analysis find security bugs early. Threat modeling and use case scenarios find design bugs early. Having an internal application security department or third party test the web application with penetration testing and ethical hacking verifies the vulnerabilities have been fixed to an acceptable level to publish the application to users.
Secure code must be: seamless, easy to understand, cognizant of attack, unobtrusive, resilient, error tolerant.

The secret to the CSSLP roles a CSSLP plays in an organization

leave a comment »

So you want to be a CSSLP.   Why is it important to become one and what will you learn?  Who are the stake holders in the organization?  

Roles a CSSLP plays within his/ her organization

  • Provides a holistic approach to software security needs
  • Gives advice regarding designing, developing and deploying secure software
  • Maintains knowledge on the latest software security technologies
  • Assists in meeting the assurance of compliance to regulations
  • Affirms compliance to the policy and procedures set








Matt Parsons, CISSP, MSM

Written by mparsons1980

January 8, 2014 at 5:37 pm

CSSLP the beginning: What is secure software development?

leave a comment »



So lets talk about what we are trying to accomplish becoming a CSSLP.   In order to be a CSSLP you need to understand the basic concepts of software security.  




  • Confidentiality– keeping data private that is sensitive.
  • Authentication– verifying the entity that they are who they say they are.
  • Session management– HTTP is a stateless protocol and this is usually managed by cookies.  States or session are sensitive.
  • Integrity-  making sure the books stay straight and that data is not modified
  • Authorization-  the entity has the clearance to do what he or she is supposed to do no more or no less.  This also ties with the principle of least privilege.
  • Exceptions management– that the software systems handles errors properly and maintains a fail safe secure state.
  • Availability  that the software system is up and running when it needs to, to support the business. 
  • Auditing– the who, what, where and when questions to an activity. 
  • Configuration management– making sure that that vulnerabilities are not introduced to software systems when making changes.

Matt Parsons, CISSP, MSM






Written by mparsons1980

January 7, 2014 at 11:40 pm