Showing posts with label complexity. Show all posts
Showing posts with label complexity. Show all posts

QOTD on Borderless Network

We've been working on an assumption that you need different levels of security for the internal network versus the external one, the Internet - the Big Bad World out there. That's been an incorrect assumption for at least ten years.
and earlier,
Start designing everything now to be externalisable.
-- Paul Simmonds, former AstraZeneca CISO, now with the Jericho Forum

Src: The key to security? Blow up the corporate wall - Computer Business Review

QOTD on the State of Security

We've approached security layer by layer. I have one tool for Web access, another tool for network access, another tool for e-mail. And yet I can't answer the basic question: Am I secure?
-- Bill Veghte, EVP of HP's software division

Src: RSA: HP Proposes Holistic Security -- InformationWeek

QOTD - In Defense of FUD

If you think buying anything, whether physical or metaphysical, can completely relieve you of fear, uncertainty, and doubt, you are naïve. People don’t work that way, and we shouldn’t. Fear, uncertainty, and doubt, at reasonable levels, keep us alive, and alert.

I am not a proponent of crippling fear any more than I am a fan of naïve confidence, but a little bit of discomfort and uncertainty can drive us to question our preparedness, and rethink the challenges we face. And that is healthy.
-- Jack Daniel, Information Security Curmudgeon & Community Development Manager for Astaro

Src: Uncommon Sense Security: In Defense of FUD

QOTD on Security Hampering Productibity

The blade guard on my power saw hampers my productivity in cutting wood, but chopping off my hand or even just a few fingers tends to also have an impact on my productivity. That said, there are a lot of very, very silly URL blocking and email policies in place out there that *do* impact productivity, *don't* increase security and *do* encourage users to bypass IT systems.
-- John Pescatore, VP Gartner Inc.

Src: SANS NewsBites Vol 12 Num 78

QOTD - @EdSkoudis on Security

Just because something is configured 'correctly' doesn't mean that the system is actually secure.
-- Ed Skoudis, co-founder of Inguardians

Src: SANS NewsBites Vol 12 Num 75

QOTD - Geer on Risk & Dependencies

The root source of risk is dependence — dependence on system state, including dependence on expectations of system state reliability. Indeed, my definition of security has co-evolved with my understanding of risk and risk’s source, to where I currently define security as the absence of unmitigatable surprise. Thus, increasing dependence results in heightened difficulty in crafting mitigations. This increasing complexity embeds dependencies in a manner that may diminish the frequency of surprises; however, the surprises will be all the more unexpected when they inevitably occur.
And that is the crux of the matter: our dependence on all things cyber as a society is now inestimably irreversible and irreversibly inestimable. That sounds more apocalyptic than I intend, but the competent risk manager always asks, “How bad could it be?” or, in the altogether American tortious style, “Who will have to pay?”
-- Dan Geer, Chief Information Security Officer for In-Q-Tel

Note: emphasis is mine

Src: Cybersecurity and National Policy | Harvard National Security Journal

QOTD - Ranum on Terminals

It's 2010, and we still have operating systems that get infected with malware and keystroke loggers and stuff like that. As long as you have got endpoints that are so easily compromised, then you are going to have this problem. It doesn't really matter whose fault it is, you are going to have this problem because the endpoint has to be a reliable terminal, and it's not.

-- Marcus Ranum, CSO of Tenable Network Security

Src:Ranum: Be Serious about Cybersecurity

QOTD - Code-powered Cars?

It takes dozens of microprocessors running 100 million lines of code to get a premium car out of the driveway, and this software is only going to get more complex.

--Robert N. Charette, writing for IEEE Spectrum

Notes:
  1. The "100 million" number is based on a quote in the article by Prof. Manfred Broy, a professor of informatics at Technical University, Munich.
  2. The article also lists figures (in millions of lines of code, or MLoC) for other technologies: F-22 Raptor (1.7MLoC), F-35 Joint Strike Fighter (5.7MLoC), and the Boeing 787 Dreamliner (6.5MLoC).

Src: IEEE Spectrum: This Car Runs on Code

QOTD on PII & De-Identification

Just as medieval alchemists were convinced a (mythical) philosopher’s stone can transmute lead into gold, today’s privacy practitioners believe that records containing sensitive individual data can be “de-identified” by removing or modifying PII [Personally Identifiable Information]. -- Narayanan, A. and Prof. Shmatikov, V.
Src: Narayanan, A. and Shmatikov, V. 2010. Myths and fallacies of "personally identifiable information". Commun. ACM 53, 6 (Jun. 2010), 24-26. DOI= http://doi.acm.org/10.1145/1743546.1743558
Direct link to PDF document

QOTD - NIST on Continuous Monitoring

NIST wrote a FAQ to answer many of the questions about Continuous Monitoring and whether it replaces the security authorization process (it does NOT).
Are there any risks associated with continuous monitoring?
Organizations should exercise caution in focusing solely on continuous monitoring at the expense of a holistic, risk‐based security life cycle approach. Without the appropriate planning for security controls (preferably early in the system development life cycle) and the correct implementation of those controls, the value of continuous monitoring is greatly diminished. This is because the near real‐time, ongoing monitoring of weak and/or ineffective security controls resulting from flawed information security requirements can result in a false sense of security.
Src: NIST FAQ
Also see NIST 800-37, Applying the Risk Management Framework to Federal Information Systems (February 2010)

QOTD on Authentication

Authentication will not be able to solve the untrusted platform problem. If you use a compromised system, authentication doesn't matter. Out of band communication will only work if the out-of band channel and associated hardware is secure, which may be questionable if devices like smartphones are used. -- Dr. Johannes Ullrich, CTO of the Internet Storm Center & Dean of the Faculty of the graduate school at the SANS Technology Institute.
Src: SANS NewsBites Vol 11 Num 98

QOTD on Humans & Complexity

While technology and information have evolved and grown dramatically over the past 100 years, people's behaviors to cope with this growth have evolved at a much slower pace and our ability to keep up with the complexity foisted upon us is limited. So today, high value is found in taming the complexity so that humans can take full advantage of these dramatic developments and advancements in technology. This is the challenge facing IT organizations around the world. -- Art Coviello, President RSA
Src: RSA Executives Offer Seven Guiding Principles To Maximize Megatrends Redefining the Information Security Industry | Reuters

QOTD - Merrill on Security, Users, and Campus Sidewalks

Douglas Merrill, former Google VP of Engineering, said, in his opening keynote:
Let users dictate enterprise security needs.
He went on to give an analogy that I am very familiar with, that of campus sidewalks: the planners place sidewalks and grass; students create their own paths through the grass (usually the most direct route); planners have to put roadblocks (chains, planters) to keep students off the grass.

He said, "security companies will change from creating infrastructure boundaries to infrastructure resilience. If we can build security correctly, we make things easier, not harder."

Src: Former Google VP Suggests User-Based Security | The Industry Standard

Primer on Security Metrics and their Pitfalls

A great primer on the utility and pitfalls of security metrics written by Vicente Aceituno:
It is not easy to find metrics for security goals like security, trust and confidence. The main reason is that security goals are “negative deliverables”. The absence of incidents for an extended period of time leads to think that we are safe. If you life in a town where neither you nor anyone you know has ever been robbed, you feel safe. Incidents prevented can’t be measured in the same way a positive deliverable can, like the temperature of a room.
Src: Security Metrics | Information Security Management Maturity Model Blog

Like Dominoes - The Anatomy Of The Twitter Attack

How many of our systems have interconnections to other systems that have weaker security? If so, remember that your ultimate level of security is that of the weakest link. This is a story about an executive, in this case the CEO of Twitter, whose Gmail account gets compromised (domino #1: password reset), which leads to leakage of corporate sensitive information that was stored with Google Docs. The intruder then covered his tracks so that the account owner would not notice (domino #2: reset password back to original by correctly guessing the CEO was using a single password for multiple accounts).

The same warning are applicable for bank accounts, phone records, insurance contracts, health records. Any account with sensitive information which uses a weaker account (e.g. most webmail applications) as a backup is likely to be a target of attackers looking for fresh prey and easy access to documents.

Src: The Anatomy Of The Twitter Attack | TechCrunch.com

It's the compiler's fault - how good source code becomes a vulnerable implementation

As a faculty having taught programming classes for many years, I have stressed the value of writing good code, with the requisite error checks. Some languages like C/C++ need to be compiled, and over the years, compilers have been augmented with the capacity to make "smart" decisions about the source code, usually to improve execution speed or warn of dangerous omissions ("you did remember to initialize that value, right?").

Brad Spengler, a security researcher, has created an instance of code where the compiler's "smart" logic actually degrades the overall security of the resulting binary by introducing a vulnerability that until now seemed un-exploitable.

After reading the SANS ISC post below, you might just be right to claim that it was the compiler's fault: "the compiler will introduce the vulnerability to the binary code, which didn't exist in the source code."

A someone who has helped grow generations of students into programmers, the suggested fix is not acceptable as it puts the burden on the programmer to know how the compiler will optimize the code. A "smart" compiler should not penalize a programmer for being extra careful with his/her code.

Src: A new fascinating Linux kernel vulnerability | SANS ISC

QOTD - Garfinkel: Privacy Requires Security, Not Abstinence

When someone can wreak havoc by misappropriating your personal data, privacy is threatened far more by the lack of a reliable online identification system than it would be by the introduction of one. And it is likely that it would cost society far more money to live with poor security than to address it. -- Simson Garfinkel, associate professor at the Naval Postgraduate School in Monterey, CA
Src: Privacy Requires Security, Not Abstinence | MIT Technology Review

QOTD on Laws & Technology

We are still living in a world where we have literally Gutenberg-era laws and businesses are using Star Wars technology... [However] New technology does not absolve an organization from its obligation to retain, produce, or manage data in any way. -- John Bace, research analyst at the Gartner Group
Src: Compliance Week: Compliance Week: Cloud Computing Vs. Internal Controls

QOTD - Rafal Los' Dose of Security Reality

In a typical company where risks are a-plenty, and IT is up to its eyeballs in delivery issues it's a little difficult to suddenly step in and talk about security vulnerabilities like they're somehow more important than the 10,000 things that are already on fire. When the whole forest is on fire... which tree do you save first?

Enterprises and SMBs alike are looking to save money, cut corners (whether they want to admit it or not) and unfortunately security sometimes falls off the docket. Whether it's the security team's fault for not properly articulating the issue or the CIO's for simply not understanding the risks... the result is often the same. Somewhere in your business are thousands of lines of insecure, exploitable, and very lucrative code. Worse yet - that stuff has been there for years and now when you review a small snip that's changing and find that the whole thing has to be re-done... no one wants to pony up the money to do the work - right? --Rafal Los, IT Security Risk Strategist, blogger at http://preachsecurity.blogspot.com/
Src: [RANT] Call Me a Realist | Digital Soapbox - Preaching Security to the Digital Masses

QOTD on Data Security for CISOs

An excellent article on CSO Online written by Andrew Jaquith for on where CISOs should focus their efforts at securing data.
Instead of trying fruitlessly to be the enterprise's all-knowing content guardian, censor authority, and compliance guru, the CISO devolves responsibility of these activities to the business. IT security becomes a clearinghouse for data security tools that business groups can use as they see fit.
As well as:
Responsibility for classifying information and restricting its flow is ultimately a business challenge, not a technical challenge. How documents, spreadsheets, and emails are used depends on workgroup and business unit preferences. So it is with data security.

That means that inside counsel owns email eDiscovery and retention, product engineering owns CAD drawings, and finance owns accounts and earnings projections. These groups know who should and should not have access and what should happen if their assets are misused. IT security's primary role should be to help source, design, and install the technical controls in place that will enable them to express and enforce their compartmentalization needs—not to be the gatekeeper.
Src: Data Security: Whose Job Is It Really? | CSO Online