I need to vent a little bit today. If you’re a security professional pay close attention. If you’re anything else, make sure your trusted security professional pays attention. If you’re a fan of football, the American version, you know what it means to do tackling drills. It’s simply getting back to the basics. All the defensive schemes, cover options, etc. are lost when you simply can’t tackle. When you, the defensive player make contact with the defensive player, you must be able to stop them. Period. End of discussion. Hit’em hard and knock them down or tie’em up long enough for your teammates to help out. If you can’t do those things you need to get back to the basics.
We information security professionals need to get back to the basics sometimes too. Far too often we get caught up in all the defensive schemes such as intrusion detection, application testing, web application firewalls, blah, blah, blah. We’ve forgotten some of our foundational techniques.
I’m going to highlight a few of these in hopes some of us will put on a “throwback” uniform and get back to the “old school” days of information security.
It’s all about information security. Information is the critical term here. Not computer, not server or network security, quite simply…information security. Our job is to protect information, regardless of its state. (Electronic, paper, verbal, etc.) This may not be true in all companies, but it should be and we as professionals need to consider this.
Risk management should be our primary motivation. Just because a risk exists doesn’t mean you need to worry about it. Let the business be your guide. As you become better at driving a car, you learn to watch the road far ahead of you and not worry so much about what’s right at your bumper. We need to do a better job at seeing the risks on the horizon and prioritizing those with the ones under our noses.
Policy and procedures matter. Efficiency is gained and errors are reduced when a process is documented and followed. Without the process, periodic failure is almost assured. We need to place more emphasis on getting systems and applications well documented before moving on to more “mature” techniques.
Location, Location, Location. If we really are worried about information, then the location of that information is critical. “Mothers, it’s 2am, do you know where your children are?” We’ve all heard it and it’s absolutely true. You can’t secure what you don’t control. Finding where your data resides and determining the risk in those locations is paramount to the success of your information security and risk management program.
Walk first, then run. Re-evaluate where you are on the maturing continuum every now and then. Have you taken any steps backwards? Are all of your process documents still valid? Do you have a valid data inventory, has your company made any acquisitions or mergers recently? Our business and technology landscapes change constantly. What makes you think your risk and security posture will remain constant.
Don’t be afraid to take a step back every now and then and run some tackling drills. It’s better to reinforce some basic ideas in a system that’s working well than to wait until everything is falling apart. We have to stop keeping up with the Jones too. Just because all your peers at a conference are buying a new technology doesn’t mean you’re ready for it. As a business owner, I’d rather be working toward maturity slowly and methodically because at some point, the going’s gonna get tough and I want to be prepared to handle it, not just have the badge that says I can.
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.