The ISO 27002 standard is the new name of the ISO 17799 standard. It really is code of practice for information security. It essentially outlines hundreds of potential control buttons and control mechanisms, which might be implemented.
The standard which is to be "established guidelines and general concepts for initiating, applying, maintaining, and bettering information security management inside an organization". The actual controls posted in the standard are proposed to address the specific requirements identified with a formal risk examination. The typical is also intended to provide a guide for the development of "organizational security criteria and effective security management methods which is also helpful in building assurance in inter-organizational activities"
ISO's future plans because of this standard are focused largely about the development and publication of industry specific types. One of the content of the ISO 27002 is information system acquisition, development, and maintenance, the details of which are as follows:-
Information Systems Acquisition, Development, and Maintenance (ISO 27002)
Table of Contents
Security Requirements of the information systems
Correct handling of the information
Security in development and support processes
Technical vulnerability Management
Overview
Information security must be studied into consideration in the Systems Development Lifecycle (SDLC) steps for specifying, building/acquiring, screening, implementing and maintaining IT systems.
Automated and manual security control requirements should be analyzed and fully recognized during the requirements level of the systems development or acquisition process, and included into business cases. Purchased software should be formally analyzed for security, and any issues risk-assessed.
The Systems Development Life Cycle (SDLC), or Software Development Life Circuit in systems and software engineering, is the procedure of fabricating or modifying systems, and the models and methodologies that folks use to develop these systems. The idea generally pertains to computer or information systems.
Systems Development Life Routine (SDLC) is an activity used by a systems analyst to develop an information system, including requirements, validation, training, and consumer (stakeholder) ownership. Any SDLC should bring about a superior quality system that fits or exceeds customer expectations, reaches completion within time and cost estimations, works effectively and successfully in the current and organized Information Technology infrastructure, and it is cheap to maintain and cost-effective to enhance
Standards
ISO 27002: Information Security Management
Clause 12: Information Systems Acquisition, Development, and Maintenance
Security Requirements of the information systems
Security can be built-into information systems acquisition, development and maintenance by utilizing effective security methods in the next areas.
Security requirements for information systems
Correct processing in applications
Cryptographic controls
Security of system files
Security in development and support processes
Technical vulnerability management
Information systems security starts with incorporating security into the requirements process for any new program or system improvement. Security should be designed into the system right from the start. Security requirements are provided to the vendor through the requirements phase of something purchase. Formal assessment should be done to determine if the product meets the mandatory security features prior to purchasing the product
Security requirements are proven to ensure as a fundamental element of the development or performance associated with an information systems. The acquisition of a system or request often carries a Request for Proposals (RFP), which is a formal procurement process. In this process, security requirements have to be identified. Indiana University or college includes both a security review and a security questionnaire as part of the RFP process. Learn more about this effective practice. The primary objective of this category is to ensure that security can be an integral area of the organization's information systems, and of the business enterprise procedures associated with those systems.
Correct handling of the information
This category aspires to prevent mistakes, loss, unauthorized modification or misuse of information in applications. Software design includes adjustments such as those to validate suggestions/output data, interior processing, and message integrity, in order to prevent erros and protect data integrity.
Input data validation Data suggestions in applications should be validated to ensure that the data is accurate and appropriate. Control includes use of both automatic and manual ways of data verification and cross-checking, as appropriate and described responsibilities and procedures for giving an answer to detected mistakes.
Control of interior processing Validation assessments should be incorporated into applications to discover the corruption of information through digesting mistakes or deliberate functions. Control includes use of both automatic and manual ways of data verification and cross-checking, as appropriate and described responsibilities and operations for responding to detected errors.
Message integrity Requirements for guaranteeing authenticity and protecting message integrity in applications should be recognized, and appropriate controls identified and carried out.
Output data validation Data productivity from applications should be validated to ensure that the processing of stored information is right and appropriate to the circumstances. Control includes use of both programmed and manual methods of data verification and cross-checking, as appropriate and described responsibilities and operations for giving an answer to detected errors.
Cryptographic control
Objective of cryptographic is to illustrate things to consider for an encryption policy in order to safeguard information confidentiality, integrity, and authenticity.
A cryptography insurance policy should be identified, covering roles and tasks, digital signatures, non-repudiation, management of keys and digital certificates etc.
Certain data, by their nature, require particular confidentiality security. Additionally, there may be contractual or other legal fines for failure to maintain proper confidentiality - when Friendly Security Numbers are participating, for example. Celebrations who may acquire unauthorized usage of the info but who do not have access to the encryption key - the "password" that encrypted the info - cannot feasibly decipher the info.
Data exist in another of three says: at break in transit or going through control. Data are especially vulnerable to unauthorized gain access to when in transit or at leftovers. Portable computers (positioning data at leftovers) are a common focus on for physical robbery, and data in transit over a network may be intercepted. Unauthorized access may also occur while data are being prepared, but here the security system may rely on the control application to regulate, and record on, such access makes an attempt. This category seeks to safeguard the confidentiality, integrity and authenticity of information by cryptographic means.
Policy on the use of cryptographic adjustments. Policies on the use of cryptographic settings for safeguard of information should be developed and integrated. Control includes
Statement of general ideas and management method of the use of cryptographic controls
Specifications based on a thorough risk analysis, that considers appropriate algorithm choices, key management and other core top features of cryptographic implementations.
Consideration of legal restrictions on technology deployments. Program, as appropriate, to data at leftovers and fixed-location devices, data transferred by mobile/detachable multimedia and embedded in cellular devices, and data sent over communications links and standards of jobs and responsibilities for execution of and the monitoring of compliance with the plan key management. Key management procedures and procedures should be integrated to support an organization's use of cryptographic techniques. Control includes techniques for distributing, stocking, archiving and changing/updating secrets recovering, revoking/destroying and dealing with compromised secrets; and logging all transactions associated with keys.
Security of the machine files
The main objective is to ensure the security of system data. Security requirements should be discovered and agreed prior to the development or acquisition of information systems.
Security requirements evaluation and specification
An examination of the requirements for security controls should be carried out at certain requirements analysis stage of each project.
Control of functional software. Steps should be carried out to control installing software on functional systems, to reduce the risk of interruptions in or problem of information services. Control includes:
updating performed only with appropriate management authorization;
updating performed only by appropriately trained personnel;
only appropriately examined and authorized software deployed to functional systems;
appropriate change management and construction control processes for all stages of upgrading;
appropriate records of the nature of the change and the processes used to execute it;
a rollback strategy in place, including retention of preceding editions as a contingency solution; and
Appropriate audit logs managed to trail changes.
Access to system files (both executable programs and source code) and test data should be operated.
To ensure that system data files and very sensitive data in trials conditions are covered against unauthorized gain access to, and that secure code management systems and processes are set up for configurations, software, and source code.
Documented strategies and revision control systems should be used to control software implementation for both applications and operating systems. New York University or college described their strategy in the display.
Protection of system test data Test data should be selected carefully and correctly logged, protected and controlled.
Access control for program source code Access to program source code should\ be restricted. Control includes:
appropriate physical and specialized safeguards for program source libraries, documents, designs, specifications, confirmation and validation programs; and
maintenance and copying of the materials subject to rigid change management and other adjustments.
Security in development and support processes
This category aspires to keep the security of request system software and information.
Change control steps The implementation of changes should be manipulated through formal change control types of procedures. Control includes:
a formal process of documentation, specification, assessment, quality control and monitored implementation;
a risk examination, analysis of actual and potential influences of changes, and specs of any security control buttons required;
a budgetary or other financial evaluation to determine adequacy of resources;
formal agreement to and endorsement of changes by appropriate management; and
appropriate notification of all affected parties preceding to implementation, on the nature, timing and likely effects of the changes;
Scheduling of changes to reduce the adverse impact on business techniques.
Information leakage Opportunities for information leakage should be properly minimized or prevented. Control includes:
risk assessment of the possible and possible mechanisms for information leakage, and consideration of appropriate countermeasures;
regular monitoring of likely information leak mechanisms and sources; and
End-user recognition and training on preventive strategies (e. g. , to remove meta-data in transferred data files).
Application system professionals should be in charge of controlling usage of [development] job and support surroundings. Formal change control operations should be applied, including technological reviews. Packaged applications should essentially not be altered. Checks should be made for information leakage for example via covert programs and Trojans if they are a concern. A number of supervisory and monitoring handles are discussed for outsourced development.
One of the security layers that can expose serious vulnerabilities is the application form layer. Inventorying and acquiring all applications, software interfaces, or integration items that "touch" hypersensitive data is vital in any corporation that deals with personal identity data, HIPAA, PCI, or any data that can lead to identifying confidential information. Alas, this layer is at the mercy of extensive variants and stretches across many technologies, individual competencies, and organizational control buttons, practices, and standards. Therefore, it is difficult to secure and sustain, usually requiring departments to re-evaluate much of their software development, acquisition, and creation control corporation, staffing, and methods. In addition, since applications are improved to adapt to changing business needs relatively often, whilst the technology they be based upon may also be changing, a consistent and "routinized" approach to keeping their security must be implemented. Fortunately, there a wide range of excellent resources to help organizations begin. a formal procedure for documentation, specification, screening, quality control and supervised implementation;
a risk examination, analysis of genuine and potential impacts of changes, and specs of any security control buttons required;
a budgetary or other financial examination to evaluate adequacy of resources;
formal agreement to and acceptance of changes by appropriate management; and
appropriate notification of all affected parties preceding to execution, on the type, timing and likely influences of the changes;
scheduling of changes to minimize the adverse effect on business processes
Technical vulnerablility Management
Technical vulnerabilities in systems and applications should be manipulated by monitoring for the announcement of relevant security vulnerabilities, and risk-assessing and making use of relevant security patches promptly.
To ensure that procedures are carried out to mitigate and/or patch complex vulnerabilities in systems and applications.
Control of internal control Validation assessments should be included into applications to identify the problem of of information through processing errors or deliberate works. Control includes: use of both programmed and manual ways of data verification and cross-checking, as appropriate; and defined responsibilities and operations for responding to detected problems.
This category is designed to reduce hazards caused by exploitation of printed specialized vulnerabilities.
Control of technical vulnerabilities Timely information about specialized vulnerabilities of information systems employed by the organization should be obtained, examined in conditions of organizational vulnerability and risk, and appropriate countermeasures taken.
Control includes:
A complete inventory of information resources sufficient to identify systems put at risk by a specific technical vulnerability;
Procedures to permit timely response to identification of technical vulnerabilities that present a risk to the organization's information resources, including a timeline based on the level of risk;
Defined assignments and duties for execution of countermeasures and other mitigation steps.
Conclusion
Sadly it is not a perfect world so when breaches of security do appear, for whatever reason, it's important to support the result by reporting the event and giving an answer to it as fast as possible.
To whom should an occurrence be reported? What information will see your face need to find out?
What safeguards should one try limit the organization's exposure to the security breach?
It is essential that all personnel know what comprises an information security event and also a security weakness and whom they record it. At the same time it is essential that management learn how to respond if they're on the escalation process for information security occurrence management reporting or escalation. It might be that there will be little if any time and energy to organise a response to the incident, in which case the more thinking which has gone in to the response method the better positioned the organisation is to offer with it. Documented and tactics information security event management procedures should be developed and practiced.
Whilst information security occurrences are not a desired outcome for any company, they need to learn, and their employees must learn, from them to prevent them taking place again. An activity of learning from such incidents by use of induction training, ongoing awareness training or other means should be carried out and all personnel, companies and third celebrations should be performed.
Remember that if the response will probably include formal disciplinary action then the full process should be officially referred to and approved by the organisational management to eliminate the probability of dispute following the event.
If evidence is to be collected it should be done by qualified staff and with credited regard for rules of evidence for the jurisdiction.
