7. Limitation of Liability YOU ACKNOWLEDGE AND AGREE THAT YOU ASSUME FULL RESPONSIBILITY FOR YOUR USE OF THE SITE AND ANY SOFTWARE OR FIRMWARE DOWNLOADED THEREFROM. YOU ACKNOWLEDGE AND AGREE THAT ANY INFORMATION YOU SEND OR RECEIVE DURING YOUR USE OF THE SITE MAY NOT BE SECURE AND MAY BE INTERCEPTED OR LATER ACQUIRED BY UNAUTHORIZED PARTIES. YOU ACKNOWLEDGE AND AGREE THAT YOUR USE OF THE SITE AND ANY SOFTWARE OR FIRMWARE DOWNLOADED THEREFROM IS AT YOUR OWN RISK. RECOGNIZING SUCH, YOU UNDERSTAND AND AGREE THAT, TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, NEITHER VTECH NOR ITS SUPPLIERS, LICENSORS, PARENT, SUBSIDIARIES, AFFILIATES, DIRECTORS, OFFICERS, AGENTS, CO-BRANDERS, OTHER PARTNERS, OR EMPLOYEES WILL BE LIABLE TO YOU FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY OR OTHER DAMAGES OF ANY KIND, INCLUDING WITHOUT LIMITATION DAMAGES FOR LOSS OF PROFITS, GOODWILL, USE, DATA OR OTHER TANGIBLE OR INTANGIBLE LOSSES OR ANY OTHER DAMAGES OR LOSS BASED ON CONTRACT, TORT, STRICT LIABILITY OR ANY OTHER THEORY (EVEN IF VTECH HAD BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES), RESULTING FROM THE SITE OR SOFTWARE OR FIRMWARE DOWNLOADED THEREFROM; THE USE OR THE INABILITY TO USE THE SITE; UNAUTHORIZED ACCESS TO OR ALTERATION OR DESTRUCTION OR DELETION OF YOUR TRANSMISSIONS OR DATA OR DEVICE; STATEMENTS OR CONDUCT OF ANY THIRD PARTY ON THE SITE; ANY ACTIONS WE TAKE OR FAIL TO TAKE AS A RESULT OF COMMUNICATIONS YOU SEND TO US; HUMAN ERRORS; TECHNICAL MALFUNCTIONS; FAILURES, INCLUDING PUBLIC UTILITY OR TELEPHONE OR INTERNET OUTAGES; OMISSIONS, INTERRUPTIONS, LATENCY, DELETIONS OR DEFECTS OF ANY DEVICE OR NETWORK, PROVIDERS, OR SOFTWARE; ANY INJURY OR DAMAGE TO COMPUTER EQUIPMENT; INABILITY TO FULLY ACCESS THE SITE OR ANY OTHER SITE; THEFT, TAMPERING, DESTRUCTION, OR UNAUTHORIZED ACCESS TO, OR ALTERATION OF, ENTRIES, IMAGES OR OTHER CONTENT OF ANY KIND; TYPOGRAPHICAL, PRINTING OR OTHER ERRORS, OR ANY COMBINATION THEREOF; OR ANY OTHER MATTER RELATING TO THE SITE OR THE SOFTWARE OR FIRMWARE DOWNLOADED THEREFROM. NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED HEREIN, VTECH'S LIABILITY TO YOU FOR ANY CAUSE WHATSOEVER AND REGARDLESS OF THE FORM OF THE ACTION, WILL AT ALL TIMES BE LIMITED TO THE AMOUNT PAID, IF ANY, BY YOU TO PURCHASE A VTECH DEVICE OR SOFTWARE. Some jurisdictions do not allow the exclusion of certain warranties or the limitation or exclusion of liability for incidental or consequential damages. Accordingly, some of the above limitations may not apply to you.
Security should be built-in, not bolt-on. Security should never be an afterthought. Secure by design, secure by default these and more have become mantra, at least in information security circles. It is clear that technology, infrastructure and services initially designed for ease-of-use, maximum compatibility or openness will appear to be constrained by the security team after the event.
A notion that has been rolling around in the sometimes preternaturally silent caverns of my cranium for a while now, and something I have brought up on the last couple of panels I have sat on, is “Are we insisting hard enough?” This is not a security issue; this is a business issue.
If “secure by design” is the ideal state, why is it that we continue to have a bolt-on Information Security function? Information Security should be embedded in the enterprise structure; a business secure by design.
Another truism is that security professionals “need to learn to speak the language of business” and I have heard many security professionals express that same desire. It is equally true that business needs to learn to speak the language of security.
Every successful breach relies on a vulnerability, but there is still a disproportionate focus on vulnerabilities in code or configuration, rather than in process or people. Frequently it is simply the way that we do something, rather than the tools that we use, that enables an attacker to gain a foothold in our enterprises. Yet we still focus on patch and vulnerability management instead of embedding security in business processes.
Some more forward-looking organisations may already be exploring the concept of “security champions” or “security ambassadors” as a component of their security awareness program, but we can and should go further. The Information Security team should be distributed and embedded throughout the organisation, empowered security experts within each business function who carry that responsibility. Our business needs to be secure by design.
Meet your new InfoSec Team
The Human Resources team, Sales, Marketing, Research & Development, Finance, whatever is relevant to your enterprise; each of these need a full-time security specialist with direct impact on departmental strategy and governance, procurement, third-party management, manufacturing, design, communications and more. Each of these reporting to the CIO/CISO with a dotted line to their own departmental heads. This is your new Information Security Team
The most obvious counter argument to this kind of structure is, of course, cost. The prospect of finding the cash to fund an extra head in every department is alarming at face value, but the more you consider how this approach translates to your own enterprise, the more attractive it becomes. It is not always an extra resource, often a redistributed one; the Information Security diaspora. This individual is a security expert, but also a full-time member of their respective team with a clear understanding of the goals, the roadmap, legislation and regulation, business requirements and drivers of that part of your business. They understand the use cases and respective urgency of technology requirements and are able to correlate the business need and the security “bigger picture”. Your embedded security resource learns new skills themselves from their departmental peers and also passes on their own security culture. Your distributed team simplifies the security audit, training, incident reporting and enhances customer experience, both internal and external.
No more marketing emails that ask your customers to “click a link to update their details”, no more ad-hoc appointment of third-party suppliers with inadequate security, no more public-facing web-servers vulnerable to SQL injections, no more shadow IT. No more.
Unparalleled visibility, integration and control, continuous education and improvement, and security embedded in every aspect of the business. Information Security is no longer the Department of No, it becomes the Department of How.
The more this architecture is adopted by leading businesses, the more secure we will make our inter-corporate communications and projects, as well. Security will find its counterpart in every partnership, you are building a secure physical API for the enterprise.
While the importance of the Chief Information Security Officer has been in constant growth over the past few years, organisations that employ a CISO/CSO are still far too few.
As the latest breach at broadband provider TalkTalk descends slowly into farce, the perils of relying on the CEO to fill these shoes become apparent. Almost one week on from the initial attack many important questions still remain unanswered or answered in unacceptably vague or contradictory terms.
The “significant and sustained” attack against TalkTalk was initially characterised as a Distributed Denial of Service attack. Commentators rightly pointed out that a DDoS in itself does not lead to information theft and that there must have been another element to it. Later reports appear to confirm that the theft was the result of a simple SQL injection attack. At a technology company! Affecting 4m people! In 2015!
TalkTalk are still unable to confirm which and how much data was encrypted. In addition to personal information including name, address, date of birth and email address, the breach also exposed financial data. The CEO initially said that they “didn’t know” if this data was encrypted or not (How can this be the case?). Now, it appears that “only” the first and last digits of credit card data may have been exposed. Of course this still carries risk, think how often those “last four digits” are requested as verification data. Since then Baroness Harding has even gone as far as the last refuge of the wicked, legislation, claiming in an interview with The Sunday Times (paywalled) that TalkTalk is under no obligation to encrypt credit card data. Really? I think that the PCI-DSS may well dispute that point with you, not to mention your customers.
Ah yes, the customers… Those four million people who will now be finding that their names, addresses, contact information and dates of birth are far more difficult to change than their credit card details (or their broadband provider) and that a year of free credit-monitoring involves entrusting yet another corporate with all their extremely sensitive information.
The handling of the breach illustrates that the role of the CISO is never a purely technical one; the CISO also owns the breach response plan, an important aspect of which has nothing to do with technology and everything to do with communications. How do you inform your customers and when? How do you engage law enforcement or forensics? What information do you need always to have to hand about the care and sensitivity with which you treat the information that has been entrusted to your organisation and how do you sensitively, accurately and promptly convey this?
Rule 1: It’s not all about you. To say, “I’m a customer myself of TalkTalk. I’ve been a victim of this attack” is crass and insensitive in the extreme. To include an assertion in your FAQ that you have not breached the Data Protection Act is both short-sighted and ill-informed, as I addressed in this piece for The Guardian.
This apparent lack of plan, this visible lack of any senior Information Security management team could well be the eventual downfall of TalkTalk, time, the markets, the regulators and their customers will decide. We could be watching the first major corporate disintegration as a result of data breach. Welcome to the future.
So, assuming you have or are planning to hire a CISO, to whom should they report? In too many organisations the CISO is still reporting to the CIO despite the frequent pitfalls. This reporting structure can be counter-productive. The question of reporting lines is often a source of friction and can really only be answered if you have managed to effectively differentiate and delineate your CIO and CISO roles.
Job descriptions are slippery amorphous things, so in the interest of impartiality I’ll use Wikipedia’s definition. CIO is “a job title commonly given to the most senior executive in an enterprise responsible for the information technology and computer systems that support enterprise goals”, whereas CISO “is the senior-level executive within an organization responsible for establishing and maintaining the enterprise vision, strategy and program to ensure information assets are adequately protected”.
When put this simply, the conflict of interest in having a CISO report to a CIO becomes very clear. The person responsible for ensuring organisational information security can not be subordinated to the person responsible for technology selection and implementation. Rather the two should operate as a team, driving operational and information security up the boardroom agenda. An effective CIO/CISO team will take board level strategic directions and translate them into technological and process requirements for the organisation. The CIO ensures that best of breed technologies are selected and architected in the most operationally beneficial manner, the CISO ensuring that those technologies meet the security requirements of the business on an ongoing basis; neither one being able to pull rank on the other.
In the case of a conflict arising between the two, which cannot be resolved through discussion the final say must comes down to business risk and operations, requiring the involvement of COO, CRO or even CEO depending on the organisational structure.
Security should be a regular boardroom agenda item and it is only through the checks and balances of the independent CIO and CISO that it can be effectively addressed.