ISO 27001 / 27002 Newsletter - Issue 16
Welcome to the latest issue of the ISO 27001 / 27002 newsletter, intended to provide news and updates regarding the information security standards.
Included in this issue are the following topics:
1) Awareness Programs (ISO 27002 8.2.2)
2) Website Hackers: Why Do They Do It?
3) Third Party Service Delivery Management
4) Information Security News
5) Disposing of Equipment (Section 9)
6) ISO 27001 / 2: Common Mistakes Part 2
7) True Story: The Sloppy Security Officer
Awareness Programs (ISO 27002 8.2.2)
The importance of awareness (ISO 27002 8.2.2) is not an issue that be over-exaggerated. It is a critical component of your organization's security. However, it is also an area which is often taken for granted, or simply not given anything like appropriate emphasis.
Often, serious breaches can be traced back to sheer ignorance, or lack of understanding, by one or more internal personnel. This picture emerges time and time again, yet time and time again little or no thought is given to improving awareness through training or other initiatives.
The most effective programs involve both short formal training sessions, and an ongoing plan. The following list of possible initiatives should hopefully stimulate some ideas on how to approach this essential topic within your own organization:
- A Security Newsletter, which can include both news and information in a topical context (please feel free to extract from this publication).
- Cheap gifts, such as pens and coffee mugs bearing a security message.
- A Screen Saver bearing security related messages
- A security DVD (assuming adequate budget).
- If your organization produces internal courses on other topics, make sure that the security angle is covered.
- Posters should be used and replaced often.
- A 'Road show' in which security personnel regularly present to senior management and staff on current issues.
- Competitions are often effective, for example, security crosswords, puzzles and problems.
Whichever route you take, building security awareness into your organization's culture is a must.
Website Hackers: Why Do They Do It?
Defacement of company websites by 'hackers' and others is a constant threat. Even the largest and most security conscious of organizations have experienced problems with respect to this But why do they do it? What is the most common motive?
The Zone-H monitoring portal performed some research on this via what is probably the largest poll ever undertaken. They reported the following as the major motives:
For fun: 35%
No reason: 19.2%
Desire to be the "best defacer": 12.5%
For a challenge: 11.7%
Other political reasons: 9.2%
Revenge against the website: 1.9%
The other disturbing aspect is the numeric dimension: this is not just a handful of individuals, but many thousand across the world.
If your corporate website is therefore of significant importance to the organization, defending it is not something that can just be left to a hosting provider. It should be treated as any other security sensitive production system, with protection commensurate with risk and potential business impact.
Third Party Service Delivery Management
ISO 27002 provides specific guidance on the implementation and maintenance of information security for organizations who receive third party service delivery. It stipulates that service agreements should be checked regularly, and compliance monitored.
Agreed security levels must be maintained by the third party covering specific service definitions and all critical aspects of the actual service managed. Where there are outsourcing arrangements in place, within periods of service interruption, the organization should ensure that security is maintained throughout this period. The organization should also ensure that the third party has suitable business continuity and disaster recovery procedures in place to meet agreed levels of continuity of service delivery.
There should be regular formal monitoring of services delivered and performance. Reports and records provided by the third party should be regularly reviewed, and audited. These procedures should ensure that the information security terms and conditions of the agreements are being adhered to in practice.
Specifically, it is important to create a regime which includes the following:
- service performance levels regularly monitored to check compliance with the agreements;
- service reports discussed at regular progress meetings as dictated by the agreements;
- information security incidents fully recorded and actions taken included in a subsequent report;
- regular scanning and checking of audit trails, records of incidents, operational problems, performance deficiencies, and fault resolutions;
In summary, the old adage "You can outsource your services, but you can't outsource your responsibility" applies to most third party service situations. It is a very important message, particularly with respect to information security.
Information Security News
1) 2008 On Track For Security Breach Record
The Identity Theft Resource Center reports that in the first three months of 2008, the number of data breaches more than doubled over the same period of last year. A rise in insider thefts is also reported.
2) Internet Crime Rises As Well
In a similar vein, IC3 (http://www.ic3.gov/media/annualreports.aspx) reports that internet-related criminal activities resulted in nearly $240 million in reported losses last year, up $40 million from 2006. Auction fraud was the most widely reported criminal activity referred to law enforcement agencies.
3) 4.2 million Card Numbers Stolen
The Hannaford Bros grocery store chain has disclosed that hackers have stolen 4.2 million debit/credit card numbers from its computer systems. The thefts occurred whilst the cards were being verified for purchase.
4) Smart Phone Attack
Researchers at Sophos (http://www.sophos.com) and McAfee (http://www.mcafee.com) have discovered a trojan that attacks the Windows Mobile smartphone platform. The devices become infected with when a user visits one of several websites in China, which is bundled in an apparently legitimate package of applications. It then lowers the security settings on the phone so it accepts unsigned programs.
5) 419 Scammers Plead Guilty
Three men pleaded have guilty in New York to running 419 spam schemes via email. A fourth defendant fled to Nigeria where he is being held pending extradition to the US. They are understood to have scammed more than $1.2 million, according to the Department of Justice. Sentencing is pending.
6) More Website Breaches
Two of the most popular websites (Expedia and Rhapsody) have recently been compromised by malicious banner ads. According to Trend Micro (http://www.trendmicro.com) the adverts utilized a Flash software interface.
Disposing of Equipment (Section 9)
Disposing of unwanted or replaced equipment brings with it a number of potential security issues:
- Legacy data from old systems can still remain accessible and thus compromise the confidentiality of information.
- Old media can still have data in situ unless de-guaged or securely erased.
- The disposal of old equipment can prevent the restoration of associated data files which may still be required.
- Equipment used infrequently may be disposed of accidentally.
- Inadequate planning for the disposal and upgrade of entire systems can threaten business continuity and result in severe loss.
- During the legitimate disposal of unwanted equipment other items can be 'lost' or stolen.
Why are we highlighting this particular issue again at this point? Because we have just heard of a significant information disclosure breach at a major international corporation. This DOES happen, more frequently than most realize.
If you haven't got one in place already, a high level policy might be something along the lines of: "Equipment owned or used by the organization should only be disposed of in accordance with approved procedures, including independent verification that the relevant security risks have been mitigated".
The topic is dealt with largely in Section 9 of ISO 27002.
ISO 27001 / ISO 27002: Common Mistakes Part 2
David Watson was one of the earliest exponents of the standards, and is one of the most well known industry figures. In the second of this series of articles for the ISO 27000 Newsletter he outlines some of the most common errors and mistakes he has encountered over the years:
Job Descriptions are rarely up to date. If they do exist, they seldom have any information security requirements in them for all staff;
Generally, little advice exists on reporting security incidents;
Contracts often do not afford adequate protection for the organization;
Rarely are references checked properly (including for sensitive positions);
I have yet to see a Contractor or a Consultants references checked to prove that they actually hold qualifications claimed. This can allow all sorts of charlatans and criminals into your organization.
There is frequently no process for HR checking of Third Parties or Contractors;
Confidentiality agreements are rarely used by the organization and are not centrally recorded. Staff signing them often do not understand what they are signing.
Often, no-one is tasked with the job of monitoring security regularly. This is frequently a part-time job for someone in IT who can be pulled off the task to do other project work;
Sometimes no security awareness or training is undertaken for staff or third parties working for the organization. Some HR departments will not touch anything to do with Consultants, Contractors or other third parties;
Too little outside contact with similar minded professionals or exchange of views with other security processionals is enabled;
Too often the Information Security Manager is an IT person who reports to the IT Department with no ability to go direct to the board. In effect, they are reporting on the people they are reporting to. The chances of serious issues getting escalated in this setup are slim, unless it is so catastrophic it cannot be hidden;
There are numerous scare stories in the press about outsourcing, but few organizations either monitor or manage outsourced contracts appropriately. There are some good contractual and outsourcing controls in A4.2.2 and A.4.3.1 of the standard;
I sometimes encounter a wholly ineffectual Information Security Forum that either rarely meets, has the wrong level staff attending, has whole business areas that do not not get involved, does not have the authority to contact the Board, and maintain no minutes for meetings.
SYSTEM DEVELOPMENT / MAINTENANCE
There is often claimed to be no development or maintenance – but on research this it is often found not to be the case;
Few standards are made available and implemented for development or change management;
Little segregation of duties or development/testing/production environment;
Testing is often omitted – there is sometimes a ‘fix on fail’ mentality as someone in Marketing (for example) has promised the delivery without consulting the Development Team. Some cynics would say that this is why Microsoft has a beta testing program, but I could not possibly comment;
Source code is sometimes accessible from live systems;
Often production data is used for testing, which could divulge either recent corporate data or personal data in breach of Data Protection legislation. This is often not properly protected during either use or at disposal.
On projects I sometimes find little (or out of date) documentation and that none of the current staff were present when the project started. This makes it impossible to determine how security was to be addressed in the project, if at all.
True Story: The Sloppy Security Officer
An Information Security Officer working for one of the biggest corporations in the world was somewhat concerned when he noticed that from time to time the "Time of last logon" to the mainframe system did not always correlate exactly with his last activity. He was not, however, concerned enough to do anything about it... until on one day, he could not logon because he was apparently already logged in! Panic began. Full paranoia mode quickly followed.
Those time of last activity warnings suddenly fell into place. He reasoned that he was being monitored by someone, and working in a security area, that 'someone' must be a person perpetrating an attack, and making sure that they were not being detected by him. He had been working on several sensitive cases recently... this must be serious.
He escalated the incident instantly, to try to catch the perpetrator whilst still logged in. The management bought his assumptions and invoked emergency procedures, closing non-critical systems and creating a 'central bridge' to investigate the activity and location of the perpetrator 'live' (heads of the major departments were paged to attend).
They traced the perpetrator's precise location: internal office... Database Administration Team... Terminal d41k12. This was a team with live database access, and there had been some costly database issues recently. So off they went, mob handed, to d41k12.
The 'perpetrator' was taken completely by surprise. He did a great job in protesting his bewilderment, claiming he was logged on as HIMSELF and had no idea what was going on. But looking at the terminal, he was clearly logged in as the Security Officer.
Then, suddenly, the Auditor spotted his name on the ID block on his desk. He had the same initials as the Information Security Officer. It surely couldn't be... or could it?
He asked him for his UserID and password. UserID = cmnjs2, CMN was the project code, with JS being his initials. The last character was #2 because on this system JS1 had already been taken (by the Security Officer of course).
Auditor to Security Officer: "And your password is January2007 too, isn't it?".
Case solved! The Database Administrator usually used cmnjs1, but couldn't on this system, and so used cmnjs2 instead. However, he sometimes forgot and went into auto-pilot during logon, thus finding himself logging in to someone else's account. When he noticed, he just logged off.
Apart from everyone's time, the losses from this incident stemmed from closure of some production systems for a couple of hours. Another loss was the total loss of credibility of the specific Security Officer in question, who was also "spoken to by senior management".
The incident did also demonstrate clearly:
- poor security awareness by staff with respect to password construction
- a lack of proper procedures for emergency management and escalation
- a culture of "rules only apply to them" within the security team, and a general sloppiness.
They were very lucky. It could have been much worse.