Bad Assumptions in Security

Published: 2014-11-08
Last Updated: 2014-11-08 21:46:52 UTC
by Tony Carothers (Version: 1)
5 comment(s)

In almost every project I have ever worked the scope is defined as part of the scope/schedule/budget of the project (as it should be), and we have to work within that scope.  In most cases that scope is set in advance by management, with little or no input regarding the impact to the system’s security.  It is almost automatically assumed that if a commercial IT offering exists, and it appears successful, then it must be secure.  The thought is ‘if it/they were not secure, how could it/they be in business?’  I see this in almost every instance when it comes to third party integrations.  However it is not always limited to web integrations, and some of the next-gen attacks that are prevalent today.  It can be as simple as stealing a password off a keyboard in another business that has access to your system. (We train our employees, but that does not mean everyone does)

Home Depot announced recently a breach that was the result of credentials issued to, and stolen from, a third party vendor.  As with any third party integration or vendor support, security must be considered with the same regard as our own internal systems and processes.  In this case, it may have been as simple as a fleet vendor who maintains the Home Depot trucks, and needed access for parts and billing.  Or maybe it was a third-party vendor stocking the shelves, who needed access to inventory levels.  It is mostly irrelevant, as their access needs to be treated with the same accord as if they were setting up a workstation on your network, and quite probably something was overlooked.  

I cannot say this loud enough: Do not assume that because a company has been in business for “x” years, or they are the hottest product on the market, that it is backed by solid security.  That is an assumption that can cost.  Dearly.

I would like to hear what other ‘bad assumptions’ that you’ve encountered.  Speak up!

tony d0t carothers --gmail

Keywords:
5 comment(s)

Comments

Bad Assumption: Taking it on faith that all relevant traffic is actually going through the devices (and ACLs) you think it is … and that your IDS/IPS is seeing it.

All security systems have the same detection rate on things that they don't see: 0%. (On the bright side, there are also 0 false positives!)
Bad Assumption: Just because the developers are experienced folks, and the complete team works on a specific OS, doesn't mean that they know computing well enough. I have seen folks exhaust storage on root directories, on both Linux and Windows, and then complain that the system won't boot up.

From a security standpoint, I have seen that project requirements often take precedence over security practices (hey, the client is paying, he doesn't want to wait, so just get it done). Eventually, you see developers running with administrative privileges, grab code snippets or 3rd-party applications, and the rest, as they say... becomes history.
Bad Assumption: Application X needs end user to be in administrator group because vendor says so.

Bad Assumption: Vendor 24/7 remote support access to application Y is secure because vendor says they have that arrangement for all their clients.

Bad Assumption: Remote database access for third-party vendor is only way to accomplish near real time data for vendor's services.
Don't assume that because a vendor has a nice client list of fortune 500 clients that their product will fix all your problems. If their integrators don't set it up right or they have assumptions on project scope that are wrong it may do nothing for you. Their product may not even be all that good to begin with, large companies make bad purchasing decisions all the time.
Because you work in the security department your computer should be white listed in the IDS/IPS system.

Diary Archives