Information Systems Acquisition Development And Maintenance Information Technology Essay

Information Systems Acquisition Development And Maintenance Information Technology Essay The ISO 27002 standard is the new name of the ISO 17799 standard. It is code of practice for information security. It basically outlines hundreds of potential controls and control mechanisms, which may be implemented. The standard which is to be established guidelines and general principles for initiating, implementing, maintaining, and improving information security management inside an organization. The actual controls listed in the standard are proposed to address the specific requirements identified via a formal risk assessment. The standard is also intended to provide a guide for the development of organizational security standards and effective security management practices and it is also helpful in building confidence in inter-organizational activities ISOs future plans for this standard are focused largely around the development and publication of industry specific versions. 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 Overview Standards Security Requirements of the information systems Correct processing of the information Cryptographic control Security of the system files Security in development and support processes Technical vulnerability Management Overview Information security must be taken into account in the Systems Development Lifecycle (SDLC) processes for specifying, building/acquiring, testing, implementing and maintaining IT systems. Automated and manual security control requirements should be analyzed and fully identified during the requirements stage of the systems development or acquisition process, and incorporated into business cases.   Purchased software should be formally tested for security, and any issues risk-assessed. The  Systems Development Life Cycle (SDLC), or  Software Development Life Cycle  in systems  and  software engineering, is the process of creating or altering systems, and the models and  methodologies  that people use to develop these systems. The concept generally refers to  computer  or  information systems. Systems Development Life Cycle (SDLC) is a process used by a  systems analyst  to develop an  information system, including  requirements, validation,  training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned  Information Technology  infrastructure, and is inexpensive 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 integrated into information systems acquisition, development and maintenance by implementing effective security practices in the following 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 begins with incorporating security into the  requirements  process for any new application or system enhancement. Security should be designed into the system from the beginning. Security requirements are presented to the vendor during the requirements phase of a product purchase. Formal testing should be done to determine whether the product meets the required security specifications prior to purchasing the product   Security requirements are established to ensure as an integral part of the development or performance of an information systems. The acquisition of a system or application often includes a Request for Proposals (RFP), which is a formal procurement process. During this process, security requirements need to be identified. Indiana University includes both  a security review and a security questionnaire as part of the RFP process. Learn more about this effective practice. The main objective of this category is to ensure that security is an integral part of the organizations information systems, and of the business processes associated with those systems. Correct processing of the information This category aims to prevent errors, loss, unauthorized modification or misuse of information in applications. Application design includes controls such as those to validate input/output data, internal processing,  and message integrity, in order to prevent erros and preserve data integrity. Input data validation  Data input in applications should be validated to ensure that the data is correct and appropriate.   Control includes use of both automatic and manual methods of data verification and cross-checking, as appropriate and defined responsibilities and processes for responding to detected errors. Control of internal processing Validation checks should be incorporated into applications to detect the corruption of information through processing errors or deliberate acts.  Ã‚   Control includes use of both automatic and manual methods of data verification and cross-checking, as appropriate and defined responsibilities and processes for responding to detected errors. Message integrity  Requirements for ensuring authenticity and protecting message integrity in applications should be identified, and appropriate controls identified and implemented. Output data validation  Data output from applications should be validated to ensure that the processing of stored information is correct and appropriate to the circumstances.   Control includes use of both automatic and manual methods of data verification and cross-checking, as appropriate and defined responsibilities and processes for responding to detected errors. Cryptographic control Objective of cryptographic is to  describe considerations for an encryption policy in order to protect information confidentiality, integrity, and authenticity. A cryptography policy should be defined, covering roles and responsibilities, digital signatures, non-repudiation, management of keys and digital certificates  etc. Certain data, by their nature, require particular confidentiality protection. Additionally, there may be contractual or other legal penalties for failure to maintain proper confidentiality when Social Security Numbers are involved, for example. Parties who may acquire unauthorized access to the data but who do not have access to the encryption key the password that encrypted the data cannot feasibly decipher the data. Data exist in one of three states: at rest in transit or undergoing processing. Data are particularly vulnerable to unauthorized access when in transit or at rest. Portable computers (holding data at rest) are a common target for physical theft, and data in transit over a network may be intercepted. Unauthorized access may also occur while data are being processed, but here the security system may rely on the processing application to control, and report on, such access attempts. This category aims to protect the confidentiality, integrity and authenticity of information by cryptographic means. Policy on the use of cryptographic controls. Policies on the use of cryptographic controls for protection of information should be developed and implemented.   Control includes Statement of general principles and management approach to the use of cryptographic controls Specifications based on a thorough risk assessment,  that considers appropriate  algorithm selections, key management and other core features of cryptographic implementations. Consideration of legal restrictions on technology deployments. Application, as appropriate, to data at rest and fixed-location devices, data transported by mobile/removable media and embedded in mobile devices, and data transmitted over communications links and specification of roles and responsibilities for implementation of and the monitoring of compliance with the policy key management.  Key management policies and processes should be implemented to support an organizations use of cryptographic techniques.   Control includes procedures for distributing, storing, archiving and changing/updating  keys recovering, revoking/destroying and dealing with compromised keys; and logging all transactions associated with keys. Security of the system files The main objective is to ensure the security of system files. Security requirements should be identified and agreed prior to the development or acquisition of information systems. Security requirements analysis and specification An analysis of the requirements for security controls should be carried out at the requirements analysis stage of each project. Control of operational  software. Procedures should be implemented  to control the installation of software on operational systems, to minimize the risk of interruptions in or corruption of information services.   Control includes: updating performed only with appropriate management authorization; updating performed only by appropriately trained personnel; only appropriately tested and certified software deployed to operational systems; appropriate change management and configuration control processes for all stages of updating; appropriate documentation of the nature of the change and the processes used to implement it; a rollback strategy in place, including retention of prior versions as a contingency measure; and Appropriate audit logs maintained to track changes. Access to system files (both executable programs and source code) and test data should be controlled. To ensure that system files  and sensitive data in testing environments  are protected against unauthorized access, and that  secure code management systems and processes are in place for configurations, software, and source code. Documented procedures and revision control systems should be utilized to control software implementation for both applications and operating systems. New York University described their approach in the presentation. Protection of system test data  Ãƒ ¢Ã¢â€š ¬Ã‚ ¢ Test data should be selected carefully and appropriately logged, protected and controlled. Access control  for program source  code  Ãƒ ¢Ã¢â€š ¬Ã‚ ¢ Access to program source code should be restricted.   Control includes: appropriate physical and technical safeguards for program source libraries, documentation, designs, specifications, verification and validation plans; and maintenance and copying of these materials subject to strict change management and other controls. Security in development and support processes This category aims to maintain the security of application system software and information. Change control procedures  The implementation of changes should be controlled by the use of formal change control procedures.   Control includes: a formal process of documentation, specification, testing, quality control and managed implementation; a risk assessment, analysis of actual and potential impacts of changes, and specification of any security controls required; a budgetary or other financial analysis to assess adequacy of resources; formal agreement to and approval of changes by appropriate management; and appropriate notification of all affected parties prior to implementation, on the nature, timing and likely impacts of the changes; Scheduling of changes to minimize the adverse impact on business processes. Information leakage Opportunities for information leakage should be appropriately minimized or prevented.   Control includes: risk assessment of the probable and possible mechanisms for information leakage, and consideration of appropriate countermeasures; regular monitoring of likely information leak mechanisms and sources; and End-user awareness and training on preventive strategies (e.g., to remove meta-data in transferred files). Application system managers should be responsible for controlling access to [development] project and support environments.   Formal change control processes should be applied, including technical reviews.   Packaged applications should ideally not be modified. Checks should be made for information leakage for example  via  covert channels and Trojans if these are a concern. A number of supervisory and monitoring controls are outlined for outsourced development. One of the security layers that can expose serious vulnerabilities is the application layer. Inventorying and securing all applications, software interfaces, or integration points that touch sensitive data is crucial in any organization that handles personal identity data, HIPAA, PCI, or any data that can lead to identifying confidential information. Unfortunately, this layer is subject to extensive variations and stretches across many technologies, human competencies, and organizational controls, practices, and standards. As such, it is difficult to secure and sustain, usually requiring departments to re-evaluate much of their software development, acquisition, and production control organization, staffing, and practices. Moreover, since applications are enhanced to adapt to changing business needs relatively often, even while the technology they depend on may also be changing, a consistent and routinized approach to maintaining their security must be adopted. Fortunately, there are many excellent resources to help organizations get started. a formal process of documentation, specification, testing, quality control and managed implementation; a risk assessment, analysis of actual and potential impacts of changes, and specification of any security controls required; a budgetary or other financial analysis to assess adequacy of resources; formal agreement to and approval of changes by appropriate management; and appropriate notification of all affected parties prior to implementation, on the nature, timing and likely impacts of the changes; scheduling of changes to minimize the adverse impact on business processes Technical vulnerablility Management Technical vulnerabilities in systems and applications should be controlled by monitoring for the announcement of relevant security vulnerabilities, and risk-assessing and applying relevant security patches promptly. To ensure that procedures are implemented to mitigate and/or patch technical vulnerabilities in systems and applications. Control of internal processing  Validation checks should be incorporated into applications to detect the corruption of of information through processing errors or deliberate acts.  Ã‚   Control includes: use of both automatic and manual methods of data verification and cross-checking, as appropriate; and defined responsibilities and processes for responding to detected errors. This category aims to reduce risks resulting from exploitation of published technical vulnerabilities. Control of technical vulnerabilities  Timely information about technical vulnerabilities of information systems used by the organization should be obtained, evaluated in terms of organizational exposure and risk, and appropriate countermeasures taken.   Control includes: A complete inventory of information assets sufficient to identify systems put at risk by a particular technical vulnerability; Procedures to allow timely response to identification of technical vulnerabilities that present a risk to any of the organizations information assets, including a timeline based on the level of risk; Defined roles and responsibilities for implementation of countermeasures and other mitigation procedures. Conclusion Sadly it is not a perfect world and when breaches of security do occur, for whatever reason, it is important to contain the result by reporting the incident and responding to it as quickly as possible. To whom should an incident be reported? What information will that person need to know? What precautions should one take to limit the organizations exposure to the security breach? It is essential that all staff know what comprises an information security incident and also a security weakness and to whom they report it. At the same time it is essential that all management know how to respond if they are on the escalation process for information security incident management reporting or escalation. It may be that there will be little or no time to organise a response to the incident, in which case the more thinking which has gone into the response procedure the better placed the organisation will be to deal with it. Documented and practices information security incident management procedures should be developed and practiced. Whilst information security incidents are not a desired outcome for any organisation, they must learn, and their staff must learn, from them to prevent them occurring again. A process of learning from such incidents by use of induction training, ongoing awareness training or other means should be undertaken and all staff, contractors and third parties should be undertaken. Remember that if the response is likely to include formal disciplinary action then the full process should be formally described and approved by the organisational management to remove the possibility of dispute after the event. If evidence is to be collected it should be done by competent staff and with due regard for rules of evidence for the jurisdiction.