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