Information Security Management System

An information security management system (ISMS) is a set of policies and procedures for systematically managing an organization's sensitive data. The goal of an ISMS is to minimize risk and ensure business continuity by pro-actively limiting the impact of a security breach.

ISO 27001 is a specification for creating an ISMS. It does not mandate specific actions, but includes suggestions for documentation, internal audits, continual improvement, and corrective and preventive action.

Chief objective of Information Security Management is to implement the appropriate measurements in order to eliminate or minimize the impact that various security related threats and vulnerabilities might have on an organization. In doing so, Information Security Management will enable implementing the desirable qualitative characteristics of the services offered by the organization (i.e. availability of services, preservation of data confidentiality and integrity etc.).

The expertise, which are necessary to implement these steps :

1.       Define ISMS Scope

Management defines the scope and the boundaries. Implementing an ISMS is an investment. Deciding and defining the scope must be done at the strategic level of the organization to ensure returns on investment.

2.       Define ISMS Policy

Normally this is done by an ISMS Cleints in consultation with ISMS Project team (composed of representatives from the scope). Draft ISMS Policy is then shoved up management's desks for review and approval.

3.       Define a Risk Assessment approach

If you have a consultant, the consultant may do this for you unless you do some research and litmus test on the various risk assessment methods to decide which fits your organization.

4.       Identify Risk

Asset owners or penetration tester if you have one.

5.       Analysis and evaluate risk

Asset owners.

6.       Perform risk treatment

Asset owners.

7.       select control objectives and control

Asset owners.

8.       Prepare a Statement of Applicability

ISMS Clients

9.       Approve residual risks

Management.

10.   Implement controls

Asset owners. Managers. To some extent this includes everybody in the defined scope. E.g. anyone using an anti-virus software, anyone closing the door at night, etc.

11.   Carry out training and awareness

Human resources for generic IS training and awareness. Members of the ISMS Project Team for more focused training per business unit.

12.   Manage Operations of the ISMS

ISMS Project Team and ISMS Clients

13.   Manage Resources

ISMS Clients

14.   Implement detective and reactive controls for security incidents

Depends on the security incident. In my recent project, physical incidents are managed by the Facilities Department. IT-related incidents by the IT.

15.   Monitor procedures and controls

Process owners and asset owners

16.   Review ISMS regularly

Internal ISMS auditors. External ISMS auditors. ISMS Clients. Risk owners. Asset owners. Management.

17.   Carry out improvement measures

ISMS Clients.

18.   Communicate the action that has been taken

Action owner.

 Firewall Policies for a Software Development Company

Major goal of Software Development Company is to design, develop and distribute software applications, framework or platform which belongs to interested domains such as finance, security, travel and tourism, healthcare, public services etc.  Different roles associated with software development company are as follows.

• Software Development Team (Software Architects, Engineers, Developers, QA Engineers, Business Analysts, Project Managers)
• Software Deployment and Support Team (Deployment Engineers, App Support Team)
• Enterprise Management (CEO, HR personnel)
• Marketing and Sales Team
• Customers and Clients

Depending on the nature of the business and the above stakeholders, the different segments of network design of Software Development Company can be listed as follows.

• Wired LAN for enterprise users
• Wireless LAN for mobile users
• Branch offices connect via WAN
• Server Rooms (File servers, Mail servers, App servers)
• Remote Data Centers and Server farms
• DMZ which interfaces with general public
• Home users connected via VPN
• Extranet for customers and clients

Before a firewall policy is created, some form of risk analysis should be performed to develop a list of the types of traffic needed by the organization and categorize how they must be secured—including which types of traffic can traverse a firewall under what circumstances.

Generally, firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy. Which kind of traffic should be blocked can be defined by firewall policy and these policies which can be applied by software development organization can be categorized as follows.

• Policies based on IP address and Protocols

Network traffic can be blocked based on source and destinations address or protocols such as FTP, HTTP

• Policies based on applications

These policies provide application layer filtering and proxy server functionality.

• Policies based on user identity

Based on user authentication by using VPN,SSL etc.

• Policies based on network activity

Based on user activities on the network.

 References :
Karen Scarfone and Paul Hoffman,"Guidelines on Firewalls and Firewall Policy" ,In NIST Special Publication 800-41, Sept 2009
(http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf)

 Automated Threat Modelling

The threat modelling process describes here is a manual process where different personnel from software development life cycle should work together. Recently there are several research works have started on automating the threat modelling process. Security testing is also labor intensive because a real-world program usually has too many invalid inputs. Also it requires engineers to have deep software security skills to carry out some of the most important steps of this process, and training them on security is expensive. So researchers are interested in finding ways to partially or fully automate the threat modelling and security testing process.

In 2012, Guifre Ruiz et al. has proposed a new automated approach to analyze software designs to identify, risk rank and mitigate potential threats to the system. They have designed a new data structure to detect threats in software designs called Identification Tree and another new data structure to classify threat countermeasures called Mitigation Trees. The information of both of these data structures has been taken from several relevant security sources and standards. They have modeled and automated approach that relies on the these data structures to identify the potential threats to a system design, to purge the less relevant threats according to the user's policies, and computes the software specifications to mitigate those threats [1].

Microsoft also introduces a threat modelling tool called Security Development Life Cycle (SDL) Threat modeling tool. It makes threat modeling easier for all developers by providing guidance on creating and analyzing threat models [2].

While threat modeling can uncover the broad threats and vulnerabilities of an embedded system, it cannot mitigate those threats. To do so, development teams must practice defensive coding, engage in frequent code reviews, and perform penetration testing.

[1]. Guifre Ruiz et al.," Automating Threat Modeling through the Software Development Life-Cycle", Sep 2012(http://research.cs.wisc.edu/mist/papers/Guifre-sep2012.pdf)
[2]. SDL Threat Modeling Tool
http://www.microsoft.com/security/sdl/adopt/threatmodeling.aspx