Tag Archives: SDLC

Application Security – The Neglected Threat

When companies like Microsoft or Oracle develop software, they have massive teams who’s only job is to try and find bugs in the software.  They also have made significant investments automated tools to help with software quality assurance.  Still Microsoft usually patches 10-20 new bugs month after month.  Oracle often patches 100 bugs a quarter.

Given these example company’s results in spite of major investments in technology and people, what does that mean for the average software development shop that doesn’t have the tools, personnel or budget that these major software shops have.

Security Compass, a Canadian company that assists Fortune 500 companies with software security issues, conducted a study of financial institutions application security practices.

Here are some of the findings of the report:

  • While most financial institutions have created security development lifecycle practices, very few of them can actually validate how well they are doing at following them.
  • Three out of four rate application security as a critical or high priority
  • 89% use the BSIMM (Building Security In Maturity Model) while almost all of the others use some form of framework or standard.
  • When it comes to metrics to measure how effective these frameworks are, most do not have a robust KPI measurement process.  Many measure raw vulnerability counts (77%),  which is a very basic measurement.
  • Less than half measure how long it takes to fix bugs.
  • Only a little more than a third track whether developers actually use the security tools called for in the policies.
  • The study showed that 58% of the banks use some third party software, but less than half of the financial institutions require their vendors to have a security development lifecycle process or even an application security policy.

These results are from financial institutions where security and process are usually front and center.  If this is the reality for organizations which have a high security awareness profile, how does the average organization rank on security process and practices.  Likely, those organizations don’t rank very well.

Smaller development shops – say with less than 50 developers likely don’t have a security development lifecycle (SDLC) process at all.  The likely don’t have automated tools to detect bad coding practices and they likely have a small (to no) quality assurance department.  If they do have a software QA department, that department is likely looking for functionality problems and not security issues and is not trained to find security problems.

If the software is developed under a development contract, that contract likely does not specify the requirements for an SDLC process or for any of the the other security processes that large software development shops have.

In addition, they likely do not conduct third party, independent, penetration tests to attempt to find those security issues.

As a result, it is likely that those custom applications are a hacker’s dream gateway into your organization and you likely will never know.

Companies that develop their own, or contract for the development of, custom software development – including web sites – need to up their game if they want to keep hackers out.  If they don’t, the hackers will continue to quietly thank them.

Information for this post came from Dark Reading.

Why Hackers Win So Easily

It might be a fair fight if companies would do just a few of the right things, but for a lot of them, they do not.

There is a form of ransomware going around now that attacks web sites rather than workstations.  Encrypting all the data on your web site will probably make you willing to pay a bigger ransom than Joe’s PC in the marketing department.  This particular attack doesn’t try to compromise the operating system; it goes after buggy plugins and addons that companies don’t seem to be able to patch.  In this case, described by Brian Krebs in his blog, the ransomware writers are going after plugins.  One they found is a shopping cart addon called Magento.  There was a patch released in February of this year and the vulnerability was disclosed in April, but still many web sites haven’t installed the patch.  PATCHING JUST THE OPERATING SYSTEM IS NOT ENOUGH – YOU HAVE TO PATCH EACH AND EVERY TOOL THAT YOU USE AND YOU HAVE TO DO IT QUICKLY.

For some ransomware victims, the problem is even bigger.  Apparently the Power Worm ransomware has a bug in it so that even if you pay the ransom, the attacker is unable to decrypt your files.

Given that this is your web site, having it offline, even for hours (and if you don’t have good backups, then maybe for days or more) is likely a problem for your business.

Now back to how the hackers get in.

They use the unpatched vulnerabilities to hack your own company’s web site.  Then they add a new page that looks like all of the other pages on your site.  Finally, they phish your employees to get them to click on a link to a web page on your own company’s web site and poof, they are in.  Once they control one machine, they escalate their permissions and propagate themselves all over your network.  It can happen VERY quickly.

So, what mistakes do companies make?

  1. Underestimate the risk of unsecure web applications. This means that you have to have a security development life cycle, test your applications and apply patches, among other things.
  2. Lack of continuous monitoring.  If you are not watching in real time what is going on in your network, you have made it pretty easy for the attackers.   Testing your web site once or even twice a year is a guaranteed fail.
  3. Lack of a disaster recovery, business continuity and incident response plan.   If you don’t plan for it and don’t test the plan, then when the kaka hits the rotating-air-movement-devices (aka when the sh*t hits the fan), you will be that proverbial deer in the headlight.
  4. If convenience or features that marketing wants always win out over security, then you give the hackers a free pass.  That does not mean that security always wins, but you need to have a clear process for evaluating security issues and understanding what risks you are willing to accept and which ones you are not willing to.
  5. Not dealing with third party security issues.  Whether it is vendor risk management (think the Target breach, Home Depot Breach or OPM breach) or third party software bugs (like the Magento bug described above), problems with a third party are your problems and if your contracts are not written correctly, you probably don’t even have any recourse to go after them for damages.  Most software licenses say that they don’t warrant that their software works correctly – you use it at your own risk.  If that software (or a third party vendor) lets a hacker in, good luck getting any money out of them.

So this is an opportunity to tighten things up and make it a little harder for the bad guys.  Maybe they will go after some other company rather than yours.

Information for this post came from Krebs on Security and CSO.