Welcome to Cyber Security Awareness week in the U.S. I love this time of year, with a whole month dedicated to the attempt to uplift my industry’s purpose in life to a more universal set of truths. Application Security is universally something all organizations need to get right, to protect their customers, their employees, their bottom line. There’s nothing but a blamestorm in the press when someone gets it wrong.
But no one is perfect. No company has all the right answers. I’ve been contemplating my own experience, surfing the government pages, and sending out queries to WhiteHat’s 150+ Threat Research Center security experts to compile the most useful tips for businesses who are prioritizing application security, especially given the upcoming online holiday season. Here are the collective tips for your dev teams and management alike:
- Be proactive and build with security in mind every step of the way. It may take a bit more time or cost a bit more money, but it’s a solid investment to prevent media embarrassment and loss of trust from your users and the public at large, which will negatively impact your business.
- Prioritize your vulnerabilities according to risk. The easiest, most dangerous vulnerabilities on your flagship application, or those applications that contain private information, should be dealt with first regardless of how difficult they are to fix. Those are the key vulnerabilities to fix.
- Patch everything. Whenever, wherever you can throughout your organization. If a patch is available, do it. I’m sorry if sometimes this makes you swear at other features the manufacturer rolled into it. Also did you know you can LOOK UP what a patch does before you install it? Ask the Internet/vendor, “Hey, there’s a patch? Is it a bug fix?” If it is a bug fix, you want it, trust me. If it’s pure feature or functionality, then you can make up your mind at a different pace, especially for legacy systems or integration issues. Test in one area if you can, then roll it out through centralized delivery.
- Blacklisting is a stop gap. It only buys you time until someone discovers some obscure way around your filter.
- Developing truly secure software requires that all of your trust assumptions be proven explicitly by your code or configuration. Just stating, “We trust ‘X'” doesn’t make it safe; that’s how app sec ended up in the state it is in today.
- Clean scans != no risk. Having the goal of a “clean” scan report and focusing only on exploitability of an issue can often be counter-productive to surfacing and remediating real risk. When you see a finding don’t ask, ” How could an attacker exploit this issue?” ask, “Have we done everything we can to ensure that all of the trust assumptions this code makes are true?”
- Scanning is best, but don’t hit retest all! Select specific, prioritized vulnerabilities you want to fix, focus on them, and use the TRC as a sounding board.
- ASP.NET classic needs an ADDITIONAL cookie. Cookies need to expire. Set a date because most of your users won’t know how to.
- Ensure cipher suits for TLS are kept up to date. As processing power increases it will become easier to break outdated ciphers, leaving your clients data at risk. Companies should also push users to keep up to date with their OS and browser updates to ensure new ciphers are supported.
- Implement preloaded HSTS on all pages to enforce HTTPS requests. Always-on HTTPS is one of the best ways to protect yourself and your users, from employees to customers sitting in coffee houses.
- Never trust incoming data. Understand how each browser handles reflected data in different ways dependent upon its location. Users are wily – they might accidentally paste the entire contents of Wikipedia into the password space. All user input should be “Sanitized” and “Output Encoded”.
- Verify that any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks. Ensure that all queries sent to the data base are parameterized queries (a.k.a. prepared statements). Use the most up to date cipher suites. Ensure that all cookies are secure and set to HTTP only.
- Do not be lulled into a false sense of security by XSS filters. Occasionally an XSS filter will flag malicious user-input in the reflected response thus: “A potentially dangerous string was detected: [injection goes here]”. Unfortunately, the injection is reproduced without sanitization and the malicious code executes.
- Instill secure coding practices with your developers. Work as a team to develop a secure infrastructure. Bring them to the table as you discuss architecture, network security, and change management. The different groups within your security ecosystem need to learn to speak the same language.
We all need to work as a team to keep users safe from hackers – and themselves.