Bad Assumptions in Security
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
Comments
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!)
Anonymous
Nov 9th 2014
9 years ago
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.
Anonymous
Nov 10th 2014
9 years ago
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.
Anonymous
Nov 12th 2014
9 years ago
Anonymous
Nov 13th 2014
9 years ago
Anonymous
Jan 11th 2015
9 years ago