If your business is working toward PCI-DSS compliance you are undoubtedly familiar with the following two requirements surrounding application security.
6.3.7 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
Installing a web-application firewall in front of public-facing web applications Both of these requirements are designed to enhance the security of applications and the databases which support them.
Here are some tips when dealing with these two requirements.
Custom code means, custom code. Even modifying the HTML on a landing page can qualify an application as having custom code. Remember, much of the interpretation during an audit is left to auditor discretion.
6.3.7 applies to both internal and external systems. Just because a customer never sees the application doesn’t exclude it from scope.
3. The code must be reviewed BEFORE being placed into production. Vulnerabilities must also be fixed prior to the system go live date.
Separation of duties is a must. If you choose to do code review internally, the person writing the code can’t check their own work.
Many organizations choose to implement both options in 6.6. The web-application firewall is used as the stop gap measure used to mitigate flaws found in an application while they are being fixed. This buys application development teams time to properly code and test the needed repairs.
Don’t forget to test the backend databases as they have as much a role in security as the rest of the infrastructure.
As our infrastructure has improved over the last few years, in terms of security, hackers have increasingly targeted application vulnerabilities. This trend is on the rise and will likely continue for the next few years. Code reviews, vulnerability scanning and penetration testing should become integral parts of your system development lifecycle as well as your long term maintenance plans.
Many an IT executive has asked me to help ensure their organization is secure. What that actually looks like on the ground is very different based on the company and culture. Some organizations view security from a point-in-time perspective. In other words, on a specific date, specific systems complied with specific requirements. Five minutes later however there can be no guarantee that changes haven’t been introduced which would impact this security posture.
I look at this from a process maturity standpoint. If you’re always chasing the regulations, you’ll be running every day and never cross the “finish line”. The regulations will change. If your security program relies on meeting the letter of the law it will always be in a state of flux.
What would be a better approach would be to assess risk and then map regulatory requirements to those activities you are already doing to reduce your risk. This methodology will do two critical things for you.
First, when the regulations change the mapping of control objectives to the regulations doesn’t require a rewrite of the controls and all the hassles that accompany this. It also ensures that your controls are written generic enough so they could be mapped to multiple regulations.
The next thing it does is ensure your organization is taking a holistic approach to security. If you relied on the federal or state law makers to tell you the adequate controls for your business you’d be misguided at best. Would you trust them to tell you the best markets to go after to secure increasing profits? I think not. Why trust them to tell you how to secure your enterprise?
Many a company has followed the letter of the law only to find out they weren’t really “secure”. I’d encourage you to approach security from a risk based model. This ensures that the time and resources you devote to security will actually yield a return on your investment. If done right, you’ll also be moving along the maturity continuum and become progressively more secure with each step. Chasing regulations will leave you with large blind spots and gaps in your overall security posture.
Tracking the IT controls that are in place for an organization doesn’t have to be a nightmare. It also doesn’t have to be expensive. It should however be organized and easy to publish.
In the past I’ve used a custom list in a Microsoft SharePoint site for several of my clients. These clients already had a SharePoint infrastructure so it was a good starting point. While SharePoint is flexible, it is not ubiquitous. There has to be a better way.
When going into an engagement we had our trusty, dusty spreadsheet of common control objectives, the control statement, testing frequency, etc. If you’re anything like me, spreadsheets are ok for about the first two pages, then I get bored and/or frustrated. I want more.
We’ve begun developing an application which will not only track the control statements and map them to compliance objectives such as SOX, HIPAA, FISMA and PCI; it will also allow you to copy in your policy statements, control test cases and testing evidence. This information is all being stored in a backend database which can be queried and reported on.
There are tools on the market today which do this and a zillion other things with high entry points. What about the organizations that wants to start small and grow into it? Or the consultant who works primarily in the SMB market where $100K just can’t be justified? That’s the market we hope to tap with this.
As with most inventions, this started out as something we needed internally to reduce the time and effort with our engagements. It filled a void. Hopefully we’ll be able to help you fill a void as well. We’re still in the development stages on this but hope to have an alpha release shortly. If you’d be interested in testing the application drop me a line.