<img height="1" width="1" src="https://www.facebook.com/tr?id=1879927395628828&amp;ev=PageView &amp;noscript=1">

Top 5 Reasons Web Applications Still Have Those Pesky Security Flaws—The Bottom Line

 Apr 19, 2017 8:59:00 AM |    Carol Mangus
Office space

I’ll admit I really love this blog. Steve Wolf tells us eloquently why 15 year old vulnerabilities are still out there roaming code bases everywhere. Seriously, a decade and a half and still the exploits exist, thriving and providing all those lovely script kiddies, international and local hackers fodder to loot and pillage your business. Would you tolerate a 15 year old perpetual accounting error? How about your board of directors? How would they like a 15 year old audit exception? Not so much? Okay, then what are you going to do about it and why? Let’s explore this using Steve’s bullets to cover all the bases:

5. Developers aren’t trained in secure coding techniques. The key point here is the following statement: “Developer training plays an important role in giving developers the expertise required to mitigate security flaws.” Yes, it does. And you’ve cut your training budget to nil—penny wise and pound foolish. How, realistically, do you expect your development staff to know how to write secure code when the business is not willing to train them accordingly? News flash: secure coding is seldom, if ever, taught in IT classes. Granted, the tide is changing, but very slowly and in all likelihood, you are not staffed with recent college grads. College grads do not understand your systems or how they support your business. Invest in training, it’s money well spent.

4. Developers don’t have the right testing tools. Well, do they? Does your business invest in security testing tools? Are they integrated into the SDLC? As this blog states “Putting these tools in the hands of developers reduces the cost to fix by allowing development teams to test for flaws before handing the code over to Quality Assurance (QA), in some cases within hours or days of introducing the flaw.” Ask a security team member what tools are needed and train the developers to use them. This is another preventative step that saves money in the long run. Re-work, as previously discussed, is expensive and unnecessary.

3. Security assessment results are poorly communicated—a report with thousands of pages of repetitive information, not correctly prioritized, summarized and effectively communicated will soon be relegated to the bottom of the pile. “Communicating those results summaries in context to managers and executives, however, is important so that they are aware of the risks they present.” Nicely put. A vulnerability management program is essential to effective remediation. Before presenting or interfacing vulnerabilities to a ticketing system, IT, or the board results should always be vetted, de-duplicated, and summarized by your security team. If you hire a 3rd party to conduct your assessments, demand that they do this as well.

2. Lack of support from above—ah, the old ostrich with its head buried defense. How’s that working for you? If you, your management team or the board think that this will hold water with auditors or regulators, I know of some good, highly experienced former executives of breached businesses who are looking for a job right now.

1. Limited Development resources. This is a recurring theme, legacy systems don’t need large teams to support them, don’t they pretty much run themselves? They’ve been around forever! The very idea that any system is static is a Tums® moment for security professionals. They are often large, complex and business-essential. Hackers don’t look at these systems with awe, they often find them ripe for the picking. If legacy code is not properly maintained, not properly secured, they are often even more susceptible to breach than newly developed systems. This requires bodies. Warm, breathing, smart, coding, security-savvy bodies. Don’t overlook what is the lifeblood of your business to save a buck in the short run, you’ll pay for it in the end.

To summarize: hire enough technical staff, support their goals, equip them to secure the code base, train them adequately, and provide understandable, achievable security findings so that they can do their jobs. There are times and places to cut budgets. Cutting development, IT training, and security to the bone will reach out and bite you in the end. And that is today’s bottom line.



Topics: Application Development

Want more of the AsTech Blog? You got it.
Blog subscribers get email updates twice a week.