A blog describing Intel's 'defense in depth' approach to information security has a neat description of the 4 main phases:
(1) Prediction (essentially risk assessment);
(2) Prevention i.e. classic preventive security controls;
(3) Detection and monitoring for threats that evade, disable or bypass preventive controls; and
(4) Response and recovery - corrective controls, a last resort.
Add a pinch of continuous improvement to learn from every event, and there you have it. Sure beats ISO/IEC 27001's somewhat simplistic plan-do-check-act model!
[By the way, Intel, the 'defense in depth' concept also applies within any of those phases e.g. using multiple information sources to broaden and deepen the analysis of security vulnerabilities in phase 1, or combining real-time alerting with near-time log anaysis in phase 3.]
Wednesday 31 October 2007
Creatures of the Net
Spooks everywhere will enjoy the University of Arizona's novel take on Hallowe'en. Four ghostly hours of security awareness on a ghoulish theme.
Now that's an idea ...
Now that's an idea ...
Which is the real First Niagra?
A trademark spat between two financial services companies reveals a deeper issue.
First Niagara Insurance Brokers use the domain FirstNiagra dotcom. First Niagara Financial Group, previously known as Lockport Savings Bank, changed its name in 2000 and tried to purchase FirstNiagra dotcom from the present owners, who refused. They then registered First-Niagra dotcom as their address for emails.
Customers of First Niagra Financial Group sometimes forget to include the crucial hyphen when emailing them, so their emails end up at First Niagra Insurance Brokers. Some emails contain sensitive information because (shock! horror!) customers sometimes send Social Security Numbers etc. in plaintext emails.
With clear evidence that customers are being confused by the similar domain names, the trademark infringement issue should't be too taxing on the judge, but this case may perhaps open Pandora's box on similar cases.
First Niagara Insurance Brokers use the domain FirstNiagra dotcom. First Niagara Financial Group, previously known as Lockport Savings Bank, changed its name in 2000 and tried to purchase FirstNiagra dotcom from the present owners, who refused. They then registered First-Niagra dotcom as their address for emails.
Customers of First Niagra Financial Group sometimes forget to include the crucial hyphen when emailing them, so their emails end up at First Niagra Insurance Brokers. Some emails contain sensitive information because (shock! horror!) customers sometimes send Social Security Numbers etc. in plaintext emails.
With clear evidence that customers are being confused by the similar domain names, the trademark infringement issue should't be too taxing on the judge, but this case may perhaps open Pandora's box on similar cases.
Tuesday 30 October 2007
ITCi Journal
The IT Compliance Institute's journal should be on your reading list if compliance is on your radar screen. The Fall 2007 issue has good articles on ISO/IEC 27001 & 27002 vs. NISTs SP800 series, symmetric encryption key management and eDiscovery.
The piece 'Holding auditors accountable for data security' is not about making internal auditors accountable for the organization's information security, but rather about the obligations on external auditors to secure privileged information they obtain during the course of audits. For a while it seemed de rigeur for big name auditors to lose laptops containing confidential client information but I can't recall any similar breaches since about 18 months ago. Did the audit firms clean up their act, or are these stories no longer newsworthy? Being of a cynical nature, I suspect the latter. Anyway, the article advises great caution when handing highly sensitive business records to the auditors, for example requiring that they are reviewed on-site and not taken away. I can almost feel the wave of horror passing across any auditors in the audience! If the organization has a strong information security policy, perhaps in response to its compliance obligations under SOX and PCI DSS, management should indeed be extremely cautious about handing information to any third party. On the flip side, though, the auditors need to be able to do their jobs and won't appreciate (further) constraints, although I guess they may just 'add it to the bill'. It is not unreasonable to insist that security compliance, confidentiality and liability aspects are incorporated in suitable clauses in the audit contract, for example by insisting that the auditors should be ISO/IEC 27001 certified. In fact, why not have your CEO formally express the importance of information security to the audit team before they start work? That's one way to make an impression ...
The piece 'Holding auditors accountable for data security' is not about making internal auditors accountable for the organization's information security, but rather about the obligations on external auditors to secure privileged information they obtain during the course of audits. For a while it seemed de rigeur for big name auditors to lose laptops containing confidential client information but I can't recall any similar breaches since about 18 months ago. Did the audit firms clean up their act, or are these stories no longer newsworthy? Being of a cynical nature, I suspect the latter. Anyway, the article advises great caution when handing highly sensitive business records to the auditors, for example requiring that they are reviewed on-site and not taken away. I can almost feel the wave of horror passing across any auditors in the audience! If the organization has a strong information security policy, perhaps in response to its compliance obligations under SOX and PCI DSS, management should indeed be extremely cautious about handing information to any third party. On the flip side, though, the auditors need to be able to do their jobs and won't appreciate (further) constraints, although I guess they may just 'add it to the bill'. It is not unreasonable to insist that security compliance, confidentiality and liability aspects are incorporated in suitable clauses in the audit contract, for example by insisting that the auditors should be ISO/IEC 27001 certified. In fact, why not have your CEO formally express the importance of information security to the audit team before they start work? That's one way to make an impression ...
Standards are for everyone else, not BSI
When I tried to notify BSI-Global (formerly the British Standards Institute) about a possible phishing email using them as a lure this morning, their automated mailing system sent me the following curt response:
So much for standards. RFC 2142 has only been out there for ten years. Perhaps BSI is above the standards that apply to us lesser mortals?
"This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
abuse@bsi-global.com"
So much for standards. RFC 2142 has only been out there for ten years. Perhaps BSI is above the standards that apply to us lesser mortals?
Resistance is useless
You know you want it: the new security compliance module.
We stripped down and completely rebuilt the 'laws, regulations and standards' awareness module last delivered 3 years ago and soon realized what business people mean when they complain about the compliance load. When you look into it, there's a huge pressure to comply with externally-mandated laws, regulations and standards, plus the rules organizations make up for themselves, the strategies, policies and contractual terms.
Being a security awareness service, we focus on the information security rules of course but I believe there are one or two non-information-security laws, regs and standards out there too ...
Saturday 27 October 2007
Iron Mountain security failures continue
Iron Mountain Inc. is back in the headlines again - this time a customer's storage media went missing from an Iron Mountain truck when the driver "did not follow established company procedures when loading the container onto his vehicle".
The backup device belonging to the Louisiana Office of Student Financial Assistance (LOFSA) contained thousands of names, birth dates and Social Security numbers. It was unencrypted - evidently LOFSA is "working on a plan to encrypt all backup data stored off site". It was also "in the process of developing our disaster and recovery plan, but [the loss] occurred before we could get it in place and establish it as a standard plan".
[Shakes head, muttering incoherently]
Tuesday 23 October 2007
Yet another redaction failure
... this time it reveals the face of a man accused of sexually abusing boys in Vietnam and Cambodia. Photos of the man were redacted using a swirly filter effect that police somehow reversed. The resulting image is clearer than most CCTV snaps we see on TV crime watch programs.
Presumably the same kind of techniques would work on similarly redacted digital photos of vehicle license plates, associates of criminals and so forth. Provided there is sufficient original data in the redacted image, and provided the manipulation can be reversed without too much data loss, it's feasible.
Stories about un-redacting documents by cutting-and-pasting the original words from 'beneath' black boxes crudely added to PDFs etc. are simply passé.
The take home lesson for today is this: if something needs to be redacted, do it properly by removing, not just manipulating or covering the original data. There's a lot to be said for the 'print out -> obliterate with marker pen -> scan -> load' method.
UPDATE: a man has been arrested in Bangkok following release of the unredacted photo.
Presumably the same kind of techniques would work on similarly redacted digital photos of vehicle license plates, associates of criminals and so forth. Provided there is sufficient original data in the redacted image, and provided the manipulation can be reversed without too much data loss, it's feasible.
Stories about un-redacting documents by cutting-and-pasting the original words from 'beneath' black boxes crudely added to PDFs etc. are simply passé.
The take home lesson for today is this: if something needs to be redacted, do it properly by removing, not just manipulating or covering the original data. There's a lot to be said for the 'print out -> obliterate with marker pen -> scan -> load' method.
UPDATE: a man has been arrested in Bangkok following release of the unredacted photo.
Saturday 20 October 2007
Automated field gun kills 9
This tragic story speaks for itself. After the operators cleared a jam in a Swiss/German Oerlikon 35mm MK5 anti-aircraft twin-barrelled gun during a live-firing military exercise, the gun turned to the left and fired a rapid burst of ½kg cannon shells directly at adjacent guns in the line, killing 9 soldiers and injuring 14. At the time, the gun was supposedly on 'manual', locked on to a target 1.5 to 2km away. On 'manual', it should not have turned at all.
According to news reports, "Defence pundit Helmoed-Römer Heitman told the Weekend Argus that if 'the cause lay in computer error, the reason for the tragedy might never be found.'" If 'computer error' equates to bug, then I can only assume the software must be horrendously complex and opaque to be so resistant to analysis ... which it probably is if it combines target acquisition/identification, range finding, gun control, oh and safety.
The South African Department of Defence is under pressure to conduct an inquiry.
Don't the procurers of such automated weaponry specify mechanical safety interlocks capable of physically preventing the turret from turning beyond set azimuth (and perhaps elevation) limits?
According to news reports, "Defence pundit Helmoed-Römer Heitman told the Weekend Argus that if 'the cause lay in computer error, the reason for the tragedy might never be found.'" If 'computer error' equates to bug, then I can only assume the software must be horrendously complex and opaque to be so resistant to analysis ... which it probably is if it combines target acquisition/identification, range finding, gun control, oh and safety.
The South African Department of Defence is under pressure to conduct an inquiry.
Don't the procurers of such automated weaponry specify mechanical safety interlocks capable of physically preventing the turret from turning beyond set azimuth (and perhaps elevation) limits?
Friday 19 October 2007
Tips for physically securing your IT equipment
A page from the University of Bristol's new security awareness site, aimed at students, offers some worthwhile advice on avoiding physical damage or loss to your IT equipment, things like:
- Don't cover the PC or monitor with anything (fire risk)
- Don't drink near the system (water damage risk)
- Don't be in a rush (a common explanation for why laptops etc. get left on public transport is that the owner was in a hurry ... I suspect asking students to get out of bed 5 minutes earlier is a bit of a tall order).
The rest of the site is straightforward enough - basic advice on antivirus, firewalls, patching, backups and so on. Not a bad start.
- Don't cover the PC or monitor with anything (fire risk)
- Don't drink near the system (water damage risk)
- Don't be in a rush (a common explanation for why laptops etc. get left on public transport is that the owner was in a hurry ... I suspect asking students to get out of bed 5 minutes earlier is a bit of a tall order).
The rest of the site is straightforward enough - basic advice on antivirus, firewalls, patching, backups and so on. Not a bad start.
Who owns what you throw away?
An interesting angle on the dumpster-diving craze comes from Singapore. A judge has previously ruled that confidential information discovered in the trash cannot be used against someone, but the issue is to go to appeal.
It seems to me the burden is and should be on the person discarding information to take care to make it unreadable, for example by cross-cut shredding and burning. It seems fair to me that it's their fault if they fail to take sufficient physical security measures to protect the information.
It seems to me the burden is and should be on the person discarding information to take care to make it unreadable, for example by cross-cut shredding and burning. It seems fair to me that it's their fault if they fail to take sufficient physical security measures to protect the information.
Subscribe to:
Posts (Atom)