Bilginin değerini hesaplamak zor iştir. Niceliksel bir bilgi ölçüm birimi olmadığı için bilgiyi ölçmek isteyenler her zaman zorlanırlar. ISO 27001 sistemi ile birlikte gelen CIA (confidentiality, integrity, availability) yaklaşımı bu konuda farklı bir açılım getiriyor. 

Şimdi sizlere bu yaklaşımı özetlemeye çalışacağım.

Bilginin Gizliliği: Kullanmakta olduğumuz bilgi ne kadar gizli? Yetkisiz kişiler tarafından erişilir ise bana yada kurumuma ne kadar zarar verir? İşimi ne kadar aksatır? Ne kadar maddi zararım olur? İtibarıma ne kadar zararı olur? Vb soruları öncelikle cevaplanmalı. Eğer bilgi yetkisiz kişiler tarafından erişildiğinde bize zarar verme potansiyeli yüksek ise bu bilgi gizlilik derecesi yüksek bir bilgidir.

Bilginin Bütünselliği: Elimizdeki bilgiyi kaybettiğimizde geriye kalan bilginin bütünlüğü ne kadar bozuluyor? Geriye kalan bilgi kullanılabiliyor mu? Geriye kalan bilgi ile kaybettiğimiz bilgiyi tekrar üretebiliyor muyuz? Bütünselliği yüksek bilgi doğruluğuna emin olunan, bozulması, yanlışlıkla değiştirilmesi kolay olmayan bilgidir. Küçük bir parçası yada tamamı kayıp edildiğinde yada değiştiğinde kurum tarafından tekrar üretilebilen bilgidir.

Bilginin Erişilebilirliği: İstediğimiz zaman, istediğimiz ortamdan yetkili kişiler tarafından erişmemiz gereken bilgi erişilebilirliği yüksek olan bilgidir. Online ortamda tutulan bilgi bilgisayarın harddiskinde tutulan bilgiye göre daha erişilebilirdir. 

Yukarıda sayılan üç kritere göre sahip olduğumuz bilgiyi sınıflandırıp puanlayabiliriz. Gizliliği yüksek, bütünselliği yüksek ve erişilebilirliği yüksek olan bilgi bizim için daha değerlidir. 

Çağımızda özellikle ülkemizin bulunduğumuz mevcut konum ve şartlarda bu sorunun cevabı kaçınılmaz ve tartışılmaz bir şekilde evet olacaktır. Beden gücünün ve işgücünün pazarlandığı, büyük kârların elde edildiği dönemleri hızlı bir şekilde geride bırakıyoruz. Dünya değişiyor ve ülkemiz bu değişime ayak uydurabilmek için önemli adımlar atıyor. Hızlı bir değişim sürecinden geçiyoruz.

Dünyada artık beden gücünü ülkemizden çok daha ucuza satabilen devler var. Çin bunlardan en önemlisi, Hindistan arkasından geliyor. Bu ülkelerde işgücü gerçekten çok ucuz. 100$’ın altındaki rakamlara bir ay boyunca çok uzun mesai şartlarında çalışacak insanlar bulunuyor. İşgücü maliyetinin inanılmaz düşüklüğüne bu ülkelerin sahip olduğu birtakım diğer avantajlar da eklendiğinde rekabet edilemez bir hale bürünüyorlar. Bu ülkeler işgücü bazlı rekabette neredeyse rakipsizler… En temel sıkıntıyı ülkemiz örneğin tekstil sektöründe ve buna benzer işgücü yoğun sektörlerde yaşıyor.

Peki ne yapmalı? Sorusunun cevabını ise çoktan fark etti Türkiye. Türkiye artık değer üretmek zorunda. Marka üretmek, markalaşmak, markalarını pazarlamak, ürettiği değerleri pazarlara sunmak zorunda. İşte bu konularda dünya ile rekabet edebilir ön plana çıkabilir. Çağımızda bütün bunları yapabilmek için kullanılacak temel hammadde ise bilgi. Markayı ancak bilgi üreterek, ürettiğimiz bilgiyi kullanıp müşteri beklentilerinin ötesine geçmeye çalışarak oluşturabiliyoruz. Markalaşmak için de bilgi ve deneyime ihtiyacımız var. Firmalar var olmak ve ayakta kalabilmek için müşterinin yalnızca bugüne ait olan ihtiyaçlarını karşılamaya değil, yarına göre planlama yapmaya, müşterilerin gelecekteki ihtiyaçlarına göre hazırlanmaya ihtiyaçları var. Bu bile zaman zaman yeterli olmayor, asıl başarıya müşterilerin farkında olmadıkları ihtiyaçları ortaya çıkararak, bunları ihtiyaçlar haline getirerek ulaşabiliyoruz.

Bilgi fark yaratmanın, değer üretmenin, markalaşmanın, yeniliğin ve inovasyonun hammaddesi olarak ele alınmalı. Bütün bunları bilgi ile inşa etmeliyiz. Bireyler için kişisel bilgi ve deneyim kurumlarda kurumsal bilgi, kurumsal hafıza ve kısmen de kurumsal kültürün karşılığıdır. Kurumlar yıllar süren çabaların ve uğraşların sonunda belirli deneyimler ve tecrübeler kazanıyorlar. İşte bu deneyim ve tecrübe tarifini yaptığımız bilgidir. Bilginin tek kaynağı kurumların kendi deneyim ve tecrübeleri değildir tabiki. Kurumların dışında üretilen bilgi de kurum için çoğu zaman değerlidir ve içselleştirilmelidir. Kurumlar bu bilgiyi kendilerine uyarlamalı ve kurumsal hafızalarına dahil etmelidir. Bu da önemli bir uğraştır ve odaklanma ve gayret gerektirir. Belirli süreç yapılarını hayata geçirmek, yazılımlar kullanmak, bu konuda kurumda kültür oluşturmak gerekir. Tüm bu çabaların neticesinde kurum üretmiş olduğu ve içselleştirdiği bilgiyi kayıt altına almaya ve erişebilir kılmaya başlar. Ama tabiki her bilgiyi herkesin erişimine sunmak doğru olmayacak, doğru bilgiyi doğru taraflara doğru zamanda erişilebilir kılmak ve güvenliğini sağlamak gerekecektir.

Bilginin güvenliğini sağlamanın üç temel ayağı vardır. Birincisi; bilginin gizliliğini güvence altına almak ve yetkisiz erişimleri engellemektir. İkincisi; bilginin kullanılabilirliğini sağlamak, ihtiyaç duyulan her anda bilgiyi ilgili tarafların kullanımına sunabilir olmak gerekmektedir. Üçüncüsü ise; bilgin bütünlüğünü korumak, belirli bir bilgi parçasının ortadan kaybolması ile tüm bilginin kullanılamaz hale gelmesi engellenmelidir. Bilginin güvenliği sağlarken tüm bu kriterler göz önünde bulunmalıdır.

Kurumlar bilginin gizliliğini sağlayamaması ve yetkisiz erişimleri kısıtlayamaması rakiplerine altın tepsi içerisinde çok değerli bilgileri sunması demektir. Bilginin kullanılabilirliğini yada erişilebilirliğini sağlayamıyorlar ise ürettikleri bunca bilginin kuruma hiçbir katkısı olmayacaktır. Bilginin bütünlüğünü koruyamamak ise kaba bir tabir ile “bir çuval inciri berbat etmek”tir. Bütünlüğünü koruyamadığımız bilgi de değerli değildir.

Some of the metrics mentioned below may be automatically generated by software/systems, some may be calculated based on values stored in other systems, and any number of these input manually. The most common source happens to be the Risk Register which highlights the importance of successfully identifying risk. For example, a system acquisition may be baselined through Risk Assessment that in turn provides the basis for metrics. Also worth noting is that compliance is just another category of risk. Whilst it may be an important form of risk to be managed, it should be managed and measured in the same way as other risks.

Information Security Policy

Information Security Policy

• Metric: Percentage (%) of each ISO 27001 section for which policies exist
• Source: Information Security Scorecard and/or Risk Register

Organisation of Information Security

Internal Organisation

• Metric: Percentage (%) of Business Units with assigned Information Asset  Owners
• Source: Roles and Responsibilities Matrix and/or Asset Register

External Organisation

• Metric: Percentage (%) of Third Party connections with accepted Risk Assessment
• Source: Risk Register

Asset Management

Responsibility for Information Assets

• Metric: Percentage (%) of assets with an assigned owner
• Source: Asset Register

Information Classification

• Metric: Percentage (%) of assets with an agreed classification
• Source: Asset Register

Human Resources Security

Prior to Employment

• Metric: Percentage (%) of employees (inc. contractors) that have been screened
• Source: HR Database and/or screening service provider

During Employment

• Metric: Percentage (%) of employees who have participated in security awareness
• Source: HR Database and/or training service provider

Termination or Change of Employment

• Metric: Percentage (%) of accounts belonging to terminated/moved employees
• Source: Identity Management System (HR Database and Account Directories)

Physical and Environmental Security

Secure Areas

• Metric: Percentage (%) of office sites with an up-to-date security plan
• Source: Physical Security Reporting

Equipment Security

• Metric: Percentage (%) of checks that have revealed unauthorised movement
• Source: Physical Security Reporting

Communications and Operations Management

Operating Procedures and Responsibilities

• Metric: Percentage (%) of production systems without critical/severe patches
• Source: Patch Management System (e.g. Microsoft System Centre Operations Manager)

Third Party Service Management

• Metric: Percentage (%) of third party connections with agreements and reporting
• Source: Risk Register

System Planning and Acceptance

• Metric: Trend of emergence and unsuccessful/reversed changes
• Source: Change Register

Protection Against Malicious Code

• Metric: Trend of malicious code detected and stopped
• Source: Anti-X systems (e.g. email, web and desktop)

Backup

• Metric: Percentage (%) of successful backups
• Source: Backup systems (e.g. tapes and SQL Server)

Network Security

• Metric: Trend of network security incidents
• Source: Network infrastructure (e.g. firewall, IDS/IPS, routers/switches)

Media Handling

• Metric: Trend of encrypted data transfers
• Source: End Point security system (e.g. USB/CD port auditing)

Exchange of Information

• Metric: Percentage (%) of Third Party links for which requirements have been met
• Source: Risk Register

Electronic Commerce Services

• Metric: Percentage (%) of online systems without critical/severe vulnerabilities
• Source: Patch and Vulnerability Management systems

Monitoring

• Metric: Percentage (%) of systems subject to active security monitoring
• Source: Asset Management and Security Event Management system

Access Control

Business Requirements for Access Control

• Metric: Percentage (%) of production systems with owners and role based rules
• Source: Asset Register and Identity Management system

User Access Management

• Metric: Percentage (%) of production systems with subject to recertification
• Source: Identity Management system

User Responsibilities

• Metric: Percentage (%) of job descriptions documented and accepted
• Source: HR Database

Network Access Control

• Metric: Percentage (%) of endpoints subject to network segregation
• Source: Network infrastructure

Operating System Control

• Metric: Percentage (%) of operating systems controlled by secure logon procedure
• Source: Operating systems (e.g. Microsoft System Centre Operations Manager)

Application and Information Access Control

• Metric: Percentage (%) of applications with a certified Access Control Plan
• Source: Identity Management system (i.e. Role Management)

Mobile Computing and Teleworking

• Metric: Percentage (%) of mobile and home workers in compliance with standards
• Source: Risk Register

Information System Lifecycle

Security Requirements

• Metric: Percentage (%) of production systems with documented requirements
• Source: Risk Register

Correct Processing in Applications

• Metric: Percentage (%) of production systems with adequate data validation
• Source: Vulnerability Management system

Cryptographic Controls

• Metric: Percentage (%) of production systems with compliant cryptography
• Source: Risk Register

Security of System Files

• Metric: Percentage (%) of production systems assessed as compliant
• Source: Risk Register

Security of Development and Support Practices

• Metric: Percentage (%) of production applications produced under version control
• Source: Risk Register

Technical Vulnerability Management

• Metric: Percentage (%) of online systems without critical/severe vulnerabilities
• Source: Patch and Vulnerability Management system

Information Security Incident Management

Reporting Information Security Events and Weaknesses

• Metric: Trend of observations received relating to information security
• Source: Risk Register

Management of Information Security Incidents and Reports

• Metric: Trend of significant information security breaches
• Source: Risk Register

Business Continuity Management

Information Security Aspects of Business Continuity Management

• Metric: Percentage (%) of Business Continuity Plans incorporating security
• Source: Business Continuity Planning system

Compliance

Compliance and Legal Requirements

• Metric: Trend of open and/or overdue legal compliance recommendations
• Source: Risk Register

Compliance with Information Security Policies, Procedures and Standards

• Metric: Trend of Information Security compliance review with no major violations
• Source: Risk Register

Information Security Audit Considerations

• Metric: Trend of open and/or overdue audit recommendations
• Source: Risk Register

What are you measuring?

If you are planning on developing a scorecard you must have something in mind to be measuring.  That may be compliance to ISO 27002 or COBIT as illustrated in the examples below, but could also be anything else you are interested in.

1.  List the components that make up the focus of your scorecard (i.e. rows)

How are you measuring?

The de-facto standard for measuring the maturity of Information Security -- or indeed any process -- is the Capability Maturity Model (CMM).  The original purpose of CMM was to assess the software development of process however it is now the basis for measuring many other processes.

Any adaptation of the CMM will usually consist of five levels; ad-hoc/chaos (1), planned/repeatable (2), defined (3), controlled/managed (4), refined/optimised (5).  You may or may not then choose to break these down using descriptors as below.  These descriptors try to aid management interpretation.

2.  List the five CMM levels and possibly any suitable descriptors (i.e. columns)

Where are you going?

If you are measuring maturity of a process you are likely to be trying to improve that process.  Like a project chart you will have a starting point, a current point and end point (or goal).  It may help to demonstrate your pragmatism if the end point for all processes is not Excellence (5)!

3.  Clearly mark your starting point, current point and end point (goal).

Example - ISO 27002 Scorecard

Example - COBIT Scorecard

Now here is a spreadsheet that will help you understand your compliance level right from the beginning to the end of your implementation process. This document has three sheets out of which two shows you the status of implementation based on each control objective and each domain.

All you need to do is to ask yourself / team / organization the question that is posted against each control and put in your answers in the column called "Findings". Once this is done, you will be able to determine the level of implementation. Put in the percentage of completion in the "Status (%)" column against each control.

The value in the "Status (%)" will be in the range of 0 -100 and you can mention NA or any other value to denote that a particular control is not applicable. Kindly note that if there is any control that is not applicable to your organization, then your cumulative results on the other two sheets will show either not completed or partial. To avoid such situation, mention Not Applicable in your findings and put in the value 100 in the status field. This will ensure that your report is accurate.

By going to the other two sheets you will be able to understand the level of implementation. This is also useful when you want to project to the management on your progress of implementation.

The graphical representation sheet will give you the graphical view of your status, which can be incorporated into your management presentation.

You can download the file here.
ISO 27001 Compliance Checklist

Note: Since the site does not allow uploads of .xls files, I have renamed this file as .pdf. All you need to do is right click on the link to download the file, save it on your machine and rename the extension back to .xls and you are ready to go. Cheers!!!

Here are the parts of the most common standards:

ISO 27002 - Information technology - Security techniques - Code of practice for information security management from the International Organization for Standardisation (ISO)

• Security Policy

• Organization of Information Security

• Asset Management

• Human Resources Security

• Physical and Environmental Security

• Communications and Operations Management

• Access Control

• Information Systems Acquisition, Development and Maintenance

• Information Security Incident Management

• Business Continuity Management

• Compliance

Control Objectives for Information and related Technology (COBIT) from the Information Systems Audit and Control Association (ISACA)

Plan and Organise

• PO1 Define a strategic IT plan

• PO2 Define the information architecture

• PO3 Determine technological direction

• PO4 Define the IT processes, organisation and relationships

• PO5 Manage the IT investment

• PO6 Communicate management aims and direction

• PO7 Manage IT human resources

• PO8 Manage quality

• PO9 Assess and manage IT risks

• PO10 Manage projects

Acquire and Implement

• AI1 Identify automated solutions

• AI2 Acquire and maintain application software

• AI3 Acquire and maintain technology infrastructure

• AI4 Enable operation and use

• AI5 Procure IT resources

• AI6 Manage changes

• AI7 Install and accredit solutions and changes

Deliver and Support

• DS1 Define and manage service levels

• DS2 Manage third-party services

• DS3 Manage performance and capacity

• DS4 Ensure continuous service

• DS5 Ensure systems security

  • Management of IT Security

  • IT Security Plan

  • Identity Management

  • User Account Management

  • Security Testing, Surveillance and Monitoring

  • Security Incident Definition

  • Protection of Security Technology

  • Cryptographic Key Management

  • Malicious Software Prevention, Detection and Correction

  • Network Security

  • Exchange of Sensitive Data

• DS6 Identify and allocate costs

• DS7 Educate and train users

• DS8 Manage service desk and incidents

• DS9 Manage the configuration

• DS10 Manage problems

• DS11 Manage data

• DS12 Manage the physical environment

• DS13 Manage operations

Measure and Evaluate

• ME1 Monitor and evaluate IT performance.

• ME2 Monitor and evaluate internal control.

• ME3 Ensure compliance with external requirements.

• ME4 Provide IT governance.

Information Technology Infrastructure Library (ITIL) Security Management from the UK Office of Government Commerce (OGC)

Control

• Implement policies

• Setup the security organization

• Reporting

Plan

• Create Security section for SLA

• Create underpinning Contracts

• Create Operational level agreements

• Reporting

Implement

• Classify and managing of IT applications

• Implement personnel Security

• Implement Secure Management

• Implement Access control

• Reporting

Evaluate

• Self assessment

• Internal Audit

• External audit

• Evaluation based on security incidents

• Reporting

Maintain

• Maintenance of Service level agreements

• Maintenance of operational level agreements

• Request for change to SLA and/or OLA

• Reporting

NIST Special Publication 800-53 Security Controls for Federal Information Systems from the US National Institute of Standards and Technology (NIST)

• Access Control

• Awareness and Training

• Audit and Accountability

• Certification, Accreditation, and Security Assessments

• Configuration Management

• Contingency Planning

• Identification and Authentication

• Incident Response

• Maintenance

• Media Protection

• Physical and Environmental Protection

• Planning

• Personnel Security

• Risk Assessment

• System and Services Acquisition

• System and Communications Protection

• System and Information Integrity

The Standard of Good Practice for Information Security from the Information Security Forum

Security Management

• SM1 High-level direction 15

• SM2 Security organisation 16

• SM3 Security requirements 17

• SM4 Secure environment 18

• SM5 Malicious attack 20

• SM6 Special topics 22

• SM7 Management review 24

Critical Business Applications

• CB1 Business requirements for security 25

• CB2 Application management 26

• CB3 User environment 28

• CB4 System management 29

• CB5 Local security management 30

• CB6 Special topics 31

Computer Installations

• CI1 Installation management 32

• CI2 Live environment 33

• CI3 System operation 35

• CI4 Access control 37

• CI5 Local security management 38

• CI6 Service continuity 40

Networks

• NW1 Network management 41

• NW2 Traffic management 43

• NW3 Network operations 44

• NW4 Local security management 46

• NW5 Voice networks 47

Systems Development

• SD1 Development management 48

• SD2 Local security management 49

• SD3 Business requirements 50

• SD4 Design and build 51

• SD5 Testing 53

• SD6 Implementation 54

End User Environment

• UE1 Local security management 55

• UE2 Corporate business applications 57

• UE3 Desktop applications 58

• UE4 Computing devices 59

• UE5 Electronic communications 60

• UE6 Environment management 62

The PCI Data Security Standard (PCI DSS) from the PCI Security Standards Council

• Build and Maintain a Secure Network

• Protect Cardholder Data

• Maintain a Vulnerability Management Program

• Implement Strong Access Control Measures

• Regularly Monitor and Test Networks

• Maintain an Information Security Policy

Most institutions are now required to conduct formal risk assessments of their IT and online security systems to ensure compliance with regulations such as: FFIEC, NERC, GLBA, BSA, NCUA, ISO 17799, ISO 27001 and many others. RiskWatch software allows the user to evaluate their risks and produces reports and graphs specifically detailing compliance within these regulations, or showing where controls are needed.

Assessment of organizations' compliance with these risk requirements can be met in up to 80% less time with the use of RiskWatch software and online services:
• An evaluation of threats vs. vulnerabilities for the client
• Simplified data collection with easy-to-use, web-based compliance surveys
• In-depth, graphic reports that detail the recommended controls to mitigate risk including both Return on Investment and Loss Impact Analysis.

Have YOU Completed YOUR Risk Assessment?

Other news covered at the board meeting includes Systems CMMI-Level 5 certification, which is on track for July 2008. The highlight of Systems' performance has been the increased business coming in from the US, on the heels of a recent award won by Systems' mortgage software.

The Observer reports:

Systems Limited declares 60pc bonus, 20pc cash dividend 

Staff Reporter

 

Islamabad—Systems Limited, Pakistan’s premier IT & IT enabled Services Company held its 31st Annual General Meeting at its registered office in Lahore. Mr. Shahid Hafeez Kardar, an eminent economist and a member of the Board of Directors of Systems Limited, chaired the meeting. During the meeting the annual accounts of the Company for the year ended December 31, 2007 were approved. The shareholders also approved the payment of 20% cash dividend i.e. Rs. 2 per share as compared to 15% cash dividend paid last year and the issue of 60% bonus shares as compared to 50% bonus shares last year. In 2007, Systems Limited’s group revenues grew by 24% year-on-year and the total employees of the group stood at over 900 as of December 2007 as compared to only 300 in 2005.

Speaking on the occasion Mr. Ashraf Kapadia-Managing Director of the Company, said “Systems Limited continues to grow at a robust pace based on the strategy defined by the company management a few years ago. With a significant number of already signed contracts and a healthy pipeline of orders, Systems Limited is expecting to grow its revenues by 30% during 2008”.

The products and software services of Systems Limited for selected industries in USA continue to get better recognition and acceptance by clients in the US, and by establishing large Business Process Outsourcing (BPO) facilities, Systems Limited has been successful in winning increased BPO services from the US market, which is a major segment for its growth and margins.

Systems Limited excels in building and delivering world class information systems. The company understands that many industries in Pakistan do not want to utilize scarce resources on branded and expensive solutions designed for different environments, and, therefore, is committed to bring its worldwide knowledge to help design industry specific IT Management Systems. Systems Limited continues to enhance its quality and delivery processes and is planning to achieve CMMI Level 5 appraisal in July 2008. It also plans to receive certification for it BPO services under ISO 27001 standard for data security and business continuity in April 2008.

BCS 2008, konfrensi taunan ini bakal digelar di Jakarta Convention Center (JCC) tanggal 18-19 november nanti, ini merupakan tahun keempat acara ini diadain. BCS08 bakal diadain barengan ama infoSEC asia Expo&Forum.

Call For Papers

selain pembicara tetap BCS jg ngundang para pembicara dari seluruh dunia dengan cara "call for papers", hhmm..."echo" dapet undangan lagi ga ya taon ini?? adapun materi dari pembahasan untuk paper, dan untuk BCS nanti adalah:

Business Topics

• ISO 27001—Information Security Management Systems (ISMS)
• Business processes & security
• Compliance management
• Handling security failure & incidents
• Banking security
• Telecommunication security
• Internet fraud
• Security awareness
• Social engineering
• Privacy, anonymity, ethics
• Cyberlaw and enforcement

Technical Topics

• 0-day hacking & security
• Penetration testing
• Telecom security/phreaking
• Secure programming
• Reverse engineering
• Exploit development
• Computer forensics
• Wireless security & hacking
• Web application security
• Cryptography
• Spyware/malware/worm/virus
• Physical security

ampun...materinya berat2...

====================================================================

info lengkapnya bisa diliat disini: BCS08

info call for paper: cfp

Establishing and maintaining an “Information Security Management System” is crucial to ISO 27001  certification. Axur ISMS ensures that the whole company will be involved in identifying new risks and implementing & reviewing controls to improve information security. It doesn’t matter if you have a small or a huge ISO 27001  scope. Axur ISMS keeps your ISMS’s tasks organized. Fosters more efficient management by triggering key ISO 27001  process and automating boring tasks – with Axur ISMS nothing impedes the forward progress of your management effort.

One of the major factors for a successful implementation of an ISMS is to know what you have to expect. The worst thing that can happen to you is that midway through the implementation you notice that an ISMS according to ISO 27001 is not what you want, is too expensive or requires too many resources to operate.

First of all, try to reflect about why you want an ISMS at all. Depending on what role you occupy within your company, the reasons might be quite different. If you're responsible for (information) security, you might have been told to do so. Or you might want an ISMS on your own account in order to adequately protect the information for are responsible for. If the latter is the case, you will need to get management support. This is one of the most important factors for a successful ISMS. It's one of the standard's requirements - but the real reason is that operating an ISMS requires resources. And lots of them.

On the one hand, you will need money to implement controls and information security safeguards. On the other hand - and more importantly - you will need a lot of your coworkers time. It's important to note that an ISMS is nothing a single person can implement. Actually the role of the security manager is to coach everyone and manage the project. Most information (e.g. for the risk analysis) has to be gathered from the managers and employees of the respective departments. Typically the managers are not too keen on spending time for these things. So it is vital to get support from top management.

If you're from top management yourself, you too need to think about your reasons. Due diligence might be a good reason, however if you only want a(nother) certificate to hang on the wall, I can guarantee that there are easier ways than getting an ISMS. I don't want to keep anyone from getting certified. However you need to be aware that a functioning ISMS not only needs to be implemented, but also operated. Operation is typically the most difficult part, because the excitement of the project is over.

My recommendation in this phase is to read the standard. If you're from top management, reading ISO 27001 will suffice. If you're responsible for security, I suggest you also have a look into ISO 27002 (formerly ISO 17799). I know it's a boring read (good pillow book if you're suffering from insomnia), but it will help to determine if an ISMS according to the standard is what you actually want. It will also help you to get a first feeling for how much work it's going to cause.

Picture of all-seeing eyes by Pulpolux

This is going to take a while. I'd like to write about the implementation in real time, or at least near real time. That means that I'll wait between posts until the things I write about can be actually done. I hope to be able to post approximately one article per week, but there will be weeks without a posting, if things take longer (e.g. conducting a risk analysis). I'm currently helping a customer build an ISMS for their organization. So that will help me to get the timing right.

My intention is this to become a group effort. I'll post my opinions about the requirements of the standard and a functioning ISMS. However I'd love to have readers post their opinions and views on the topic. I hope to finish the first posting by the end of the week.

Picture of shaking hands by Jeff Bauche

It is like a check list for programmers and testers to give a crowning touch to their codes/programs/applications/websites; although all steps may not be applicable to your applications but you can definitely use the ones which seem useful to you.  

I would appreciate all the technical people who read this article, if they jot their comments, suggestions for missing points and for mistakes/in accuracies, so that we all together can create a prime checklist for defining a completely new and secure vertical for the programmer and tester community across the globe. 

Testing redefined: Creating secure applications 

1. Test the application for multi-languages, multi-time zones, multi-browsers, multi-screen sizes, multi-platforms whichever are applicable
2. Test the application for key board short cuts, tooltips for form elements, dropdown heights/widths, textbox height/widths and overall symmetry
3. Test the application for formatting, location, window sizes of all user friendly warning/error messages and their respective triggers
4. Test the application for SQL Injection (exploits a security vulnerability occurring in the database layer of an application)
5. Test the application for illegal (over limit, under limit, different data types, null) inputs
6. Test the source code for “Reflection”, hence no variable/class/method names should be hard coded
7. Print all the output reports and test them for alignment, proper page breaks, formatting, paper size, data readability and completeness
8. Test the application for scalability to various databases, programming languages, operating systems and define a schedule for migration, minimum requirements - hardware, software and non-possible migrations
9. Create and test the backup schedule, backup copies should be placed in a different location, following the BCP-DR (Business continuity planning – Disaster recovery) procedure for ISO 27001. Backup schedule should be periodical i.e. daily, weekly, fortnightly, monthly, quarterly depending on the data availability factor for the application users
10. Maintain all the necessary documentation: commenting the code, flow chart, database design/schema, table design/scheme, user manual, source code/files naming conventions, ER diagram, help files, researched material etc
11. Test the application for SOX (The Sarbanes-Oxley Act) compliance, following the SOX compliant controls from ISO 27001
12. Three levels of testing should be practised:
13. Programmer’s testing for illegal inputs, source code verification, code optimisation, appropriate documentation, testing all permutations and combinations of inputs and respective outputs
14. Tester’s testing with a hacker’s perspective to break into/through the application and find all the loop holes possible. No security loop holes should be found once this testing is achieved
15. Users/Beta testing focussing towards user friendliness and aesthetic side of the application. Ease of use, efficiency, quick outputs in the desired formats, correctness and completeness are key points here
16. Encrypt/encode the source code and place it in a secured network drive
17. Create a schedule to backup source code or maintain versions with proper naming conventions using timestamp, programmer’s name, version number and maintain necessary documents (soft/hard copy) explaining the reasons for shifting to the newer version. Amend the documentation every time a new version is released, if version maintenance is applicable

In the meantime I have actually gotten my hands on the BIP 0074 Book "Measuring the effectiveness of your ISMS implementation based on ISO/IEC 27001" by Ted Humphreys and Angelika Plate. I have to admit that I was surprised at how good it is. If you can afford the 35 GBP (not quite 70 USD), I strongly recommend you get a copy and read it yourself. In this multi-part posting, I'll write up a short summary, so you know what you'll get.

First of all, the book makes an important distinction: there is a notable difference between measuring the effectiveness of your ISMS and measuring the effectiveness of the controls you've implemented. Both are required by ISO/IEC 27001:2005.

Also note the consistency in the approach of ISO 27001: In the Do phase of the PDCA model you need to create a concept of how you are going to do your measurements (requirement 4.2.2.d), the actual measuring takes place in the Plan phase (requirements 4.3.2.b and 4.3.2.c).

What I really do like about BIP 0074 is that it gives examples for metrics and measures for all kinds of controls. In ISO 27001 - The Good and the Bad (Part III), I wrote that you can't measure the effectiveness of management controls like the information security policy. Actually, this is the first example in the book. Aspects relevant to metrics and measures of this control are:

• the policy needs to be agreed, approved and communicated to all employees;
• it should be ensured that the employees understand the policy;
• it should be reviewed and updated as and when appropriate to keep up-to-date with business objectives.

Yes, I need to agree that this are in fact things that can be measured. This is an approach you can use for practically all controls: just look which of the requirements in ISO 27002:2005 (formerly ISO 17799:2005) can be backed up with indication figures, and use those to measure the effectiveness.

In part II of this posting, I'll cite an example for technical controls.

Picture of an old measure tape by aussiegal

I have no idea why, but my posts about ISMS are those that get by far the most hits. So I'll continue the series ISO 27001 - The Good and the Bad (here are the links to Part I and Part II) with the topic I already mentioned yesterday: Measuring the effectiveness of controls.

The corresponding requirement can be found in clause ISO 27001:2005 4.2.2d. In the words of the standard, it sounds like this:

Define how to measure the effectiveness of the [...] controls [...] and specify how these measurements are to be used to assess control effectiveness to produce comparable and reproducible results [...].

Ted Humphreys himself said that the requirement is not very clear. First off, it is important to note that this is one of three control mechanisms. The first is the internal auditing and management reviewing that is required by the standard. The second is the incident management that must be implemented and used to identify potential vulnerabilities and close them via corrective and preventive actions.

We're talking about the third one: Measuring the effectiveness of controls. Let's go through the clause word by word. The first thing that sicks out is that there is no limiting element in there. In theory you'd need to measure the effectiveness of each and every control you implemented in your ISMS. While measuring the performance of technical measures is not easy but at least doable by specifying key figures, measuring the performance of organizational controls is outright impossible. How are you supposed to find out how effective your security policy is? In a way that is reproducible? Forget it! What about screening? The only thing you can find out is when it was not effective. But by then it will be too late.

While I think the requirement itself does make sense, I would expect some guideline for which controls the measurement must be implemented. Doing all controls is definitely impossible.

The second thing which in my humble opinion is unclear is how to measure the effectiveness. Using key figures is just a guess from my side. The auditor I accompanied a couple of months ago seemed to have the same opinion. It would definitely help to if they included just a sentence with some guidance.

This guidance is going to be provided by a standard of its own, ISO 27004. The only problem is that it is still not available. Some people expect it to become available this year, but I personally think it won't be released until 2009 (though I hope I'm wrong). However what is available today is the BIP 0074:2006 standard. It's called "Measuring the effectiveness of your ISMS implementations based on ISO/IEC 27001". ISO 27004 can be expected to be based on the BIP book. Unfortunately I did not yet have the chance to read it. If I can get hold of a copy, I'll post an article about it here.

Alright, it's become quite a long article. I'll call it a day. If I forgot anything, please drop me a line in the comments section. Thanks!

Picture of an object of which I have no idea what it is, but which must have something to do with measuring by spacesuitcatalyst