Securing Your Information SystemsExpert Perspective — By Jerod Brennen on November 30, 2012 at 8:00 am
This article is part nine in a twelve-part series on information security fundamentals for small and medium-sized businesses.
Your IT staff has worked day in, day out to ensure that your network, computer systems, and customer data are secure. So what’s the quickest way to undo all their hard work? Simple: Add a new system to the network without telling them.
When it comes to maintaining a secure network, one critical step is to document the security requirements for new systems. Each system needs to be configured securely before it’s added to network. Remember: a chain is only as strong as its weakest link. If you allow employees to bring in unpatched systems running insecure services, you will effectively hamstring your IT staff’s security efforts.
Speaking of patching, you should also have a process in place to identify and patch all critical technical vulnerabilities. Attackers craft both network and phishing attacks to exploit technical vulnerabilities in order to take over target systems. If you are using a vulnerability scanner and an automated patch management tool to stay on top of these vulnerabilities, you can shut down these attacks before they even begin.
It’s important that you monitor both systems and applications for vulnerabilities. You’re patching Windows? Great! What about Adobe Acrobat Reader, Java, Flash, Firefox, Chrome, and every other application installed on your end user systems? Ignoring these apps is equivalent to locking the front door but leaving the windows, the back door, and the garage door wide open.
Although software vendors are constantly releasing security patches for their products, security vulnerabilities can also be introduced as part of a system or application change. When the IT department deploys a new version of your customer relationship management software, are you certain that they didn’t also (unknowingly) deploy a config file that contains default system usernames and passwords? Implementing a process to review system security after every change will help you avoid this type of exposure.
If your organization is large enough to develop your own applications, you’ll need to document an Application Development Policy. Readers of this series are keenly aware of the emphasis placed on setting expectations in policy, and application development is no exception. At a minimum, this policy should require testing on non-production systems and prohibit testing with sensitive production data.
As tempting as it may be to copy all of the customer credit card numbers to a less secure non-production system, it’s a bad idea. Seriously. Use test credit card numbers instead.
When it comes to web application security, the one control that will result in the most bang for its buck is to require that all applications enforce input validation. Simply put, input validation is a process that makes sure all data entered by users is both safe and correct before sending that data to the server.
An attacker could exploit an input validation flaw to bypass the application security controls and take over both the application and the server that it resides on. According to the Open Web Application Security Project (OWASP), input validation is the most important web application security control you can implement. Period.
Organizations that handle sensitive customer data, especially credit card data and electronic protected health information, will also need to document data protection requirements in an Encryption Policy. You should be just as concerned about the strength of your encryption keys as you are about the ability to recover customer data if those encryption keys are lost or corrupted. Losing the ability to decrypt customer data can be more damaging than a data breach. That’s why you also need detailed procedures on how you will protect your encryption keys from both loss and compromise.
With all of these preventative controls in place, you need to make sure that you’re not overlooking your detective controls. What good are all of the controls that keep the criminals out when you may have a compromised internal user on your payroll?
Let’s forget criminals for a moment and consider the non-technical user who is just trying to do his or her job. Does that user know it’s not okay to email an unencrypted spreadsheet of social security numbers to your third party HR provider? By implementing a detective control to monitor outbound messages for information leakage, you can catch the unscrupulous insiders and identify employees who may need to attend another security awareness training class.
To recap, every business owner should do the following:
- • Document security requirements for new systems
- • Patch all critical (exploitable) technical vulnerabilities
- • Monitor systems and applications for vulnerabilities
- • Review system security after every change
- • Document an Application Development Policy
- • Prohibit testing with sensitive production data
- • Enforce input validation on all applications
- • Document an Encryption Policy
- • Protect encryption keys
- • Monitor outbound messages for information leakage
In the next article, we’ll tackle Security Incident Management.
By day, Jerod Brennen is a principal security consultant with Jacadis, an award-winning security solutions and services provider. By night, he’s a husband, father, writer, filmmaker, martial artist, and social media junkie. Jerod has more than a decade of information technology, infosec, and compliance experience. He spent years as an information security specialist with American Electric Power before moving to Abercrombie & Fitch to build out and manage its information security program. Jerod’s approach to infosec has two key tenets: don't be afraid to void warranties, and you shouldn't need to bypass security to get your work done. Follow him on Twitter at @slandail.
Leave a Reply
You must be logged in to post a comment.