Your SlideShare is downloading. ×
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
DS-5
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

DS-5

592

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
592
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Michigan Department of Information Technology CONTROL SELF-ASSESSMENT QUESTIONNAIRE Delivery & Support Ensure System Security The Control Self-Assessment process is designed to help you improve your internal control environment. The attached questionnaire is an important part of this process. Please complete the questionnaire and return it to the audit team. You may either type or write your answers (whichever is easiest for you). Note that, due to the formation of the Department of Information Technology (DIT), many IT related responsibilities that were formerly assumed by agency/department management have shifted to DIT management. DIT management is responsible for the State of Michigan’s entire general control environment. In addition, DIT Management is the business process/application owner for DIT applications and holds responsibility for managing the applications and application environment. If you have any internal control exceptions or issues, please document them on the final page(s) and develop a corrective action plan. If you have an exception or issue that has already been fully corrected, you do not need to document it in the questionnaire. If the item has been partially corrected, please document this in the questionnaire. This questionnaire should be completed by the person who actually does the work in this area and not by a supervisor or manager. A company supervisor or member of management should then review the answers before the questionnaire is returned to the auditor. When the auditor(s) arrive at your location, they will review your completed answers and will test a sample of your questions to validate whether the questions were answered accurately. If the testing identifies that the questions were answered correctly, then the audit work for this area is complete. It is important that you answer all questions accurately and honestly. If the auditor’s testing identifies that not all questions were answered correctly, then the auditor(s) will perform additional detailed audit work. You may also use this document to perform your own “self-audit” at any time. Internal Audit encourages the use of this questionnaire for conducting self-assessments (audits) during those years when a visit by Internal Audit is not scheduled. This practice will help to prevent or detect internal control weaknesses in a timely manner. If you use the forms for a self-audit, you do not have to send any documents to Internal Audit. You also are not required to inform Internal Audit that you are performing a self-audit, nor are you required to report any internal control exceptions or issues. However, if you would like assistance from Internal Audit, please contact John Juarez, DIT Internal Auditor (at extension 12713), or Kathy Krause, Senior IT Auditor (19865). These self-audit exceptions or issues will not be reported. Thank you for using Control Self-Assessment!
  • 2. Michigan Department of Information Technology CONTROL SELF-ASSESSMENT QUESTIONNAIRE Delivery & Support – Ensure System Security High Level Control Objective To safeguard information against unauthorized use, disclosure or modification, damage or loss.
  • 3. Michigan Department of Information Technology CONTROL SELF-ASSESSMENT QUESTIONNAIRE Delivery & Support – Ensure System Security Summary of Controls Existence and Performance Levels for Detailed Control Objectives Effectiveness/ Control Objective Existence (*) Performance (**) 5.1. Manage Security Measures D ND DNE NA E VG S I NA 5.2. Identification, Authentication and Access D ND DNE NA E VG S I NA 5.3. Security of Online Access To Data D ND DNE NA E VG S I NA 5.4. User Account Management D ND DNE NA E VG S I NA 5.5. Management Review of User Accounts D ND DNE NA E VG S I NA 5.6. User Control of User Accounts D ND DNE NA E VG S I NA 5.7. Security Surveillance D ND DNE NA E VG S I NA 5.8. Data Classification D ND DNE NA E VG S I NA 5.9. Central Identification and Access Rights D ND DNE NA E VG S I NA Management 5.10. Violation and Security Activity Reports D ND DNE NA E VG S I NA 5.11. Incident Handling D ND DNE NA E VG S I NA 5.12. Reaccreditation D ND DNE NA E VG S I NA 5.13. Counter-Party Trust D ND DNE NA E VG S I NA 5.14. Transaction Authorization D ND DNE NA E VG S I NA 5.15. Nonrepudiation D ND DNE NA E VG S I NA 5.16. Trusted Path Functions D ND DNE NA E VG S I NA 5.17. Protection of Security Functions D ND DNE NA E VG S I NA 5.18. Cryptographic Key Management D ND DNE NA E VG S I NA 5.19. Malicious Software Prevention, Detection and D ND DNE NA E VG S I NA Correction 5.20. Firewall Architectures and Connections with Public D ND DNE NA E VG S I NA Networks 5.21. Protection of Electronic Value D ND DNE NA E VG S I NA Legend (*) D = Documented, ND = Not Documented, DNE = Does Not Exist, NA = Not Applicable (**) E = Excellent, VG = Very Good, S = Satisfactory, I = Ineffective, NA = Not Applicable
  • 4. - Legend - Control Objective: High-level and detailed generic statement of minimum good control. Question(s): Questions answered in addressing this control objective. Guidance: Examples of control practices, which are practical rationale and guidance on how to implement the control objective. Existence: The existence of the control(s) and whether it is documented is noted here. Performance/ Effective- The effectiveness of the control and its current performance level (excellent, very good or ness: satisfactory). Person/Area Identify the specific divisions, application owners/user agencies, vendor/contractor, etc. of Responsi- responsible for this internal control. bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Description, explanation and documentation of Describe and explain how the control(s) Control(s) & the control(s). are monitored. Monitoring Activities:
  • 5. Control 5.1- Manage Security Measures Objective: IT security should be managed such that security measures are in line with business requirements. This includes: • Translating risk assessment information to the IT security plans • Implementing the IT security plan • Updating the IT security plan to reflect changes in the IT configuration • Assessing the impact of change requests on IT security • Monitoring the implementation of the IT security plan • Aligning IT security procedures to other policies and procedures Question(s): Does the security strategy provide solutions for the real business challenges or needs? Is the security strategy synchronized with the overall business plan? Has exposure to new vulnerabilities been avoided? Have all implications been considered and the latest technology evolution taken into account? Have targets been established for which progress can be measured? Is appropriate security implemented and maintained? Are security requirements, objectives, policies, standards and procedures consistent with applicable laws and regulations? Are individual security responsibilities defined clearly? Do employees have the required knowledge of the organization’s security-related policies and procedures as well as the appropriate security-minded attitude? Has asset ownership been established? Guidance: • The need to prepare and maintain a technological strategic and tactical security plan should be laid down in a policy. • The responsibility for the preparation, maintenance and approval of such strategic and tactical security plans (including succession plans) should be identified, and the required skills for this task available within the organization. Senior management from across the organization should be involved. • Independent advice (internal or external) and comment on the security plan should be solicited prior to the plan’s implementation. • The security strategy should be linked into the overall operating plan/strategy, the security policy, security standards and security practices/guidelines. Management should challenge and review the strategy periodically and ensure it remains in line with the strategic business plan.
  • 6. Manage Security Measures – Guidance, continued • The security strategy should specify the path to the desired level of security in measurable terms by relating progress to benchmarks. • The security strategy should have metrics that are benchmarked against industry scores. Independent reviewers should validate metrics scores. • The security strategy should be based on a formal risk analysis, taking into account that risk has many different components: assets, threats, vulnerabilities, safeguards, consequences and likelihood. • Detailed plans should be formulated and documented to implement the security strategy, resulting in the development and implementation of a better computer security program and in the better protection of systems and information. • Security requirements, objectives, policies, standards and procedures should be identified, documented and published. • Documented security requirements, objectives, policies, standards and procedures should be consistent with applicable laws and regulations and with contractual, legal and other service level agreements. • A process for communicating the strategy, plans, policies and procedures should exist, insuring that the policy has visibility and that clear mandates, roles and responsibilities are defined and updated as the environment changes. • Senior management should refer to the security strategy and encourage staff to do so. • The security responsibilities of managers and employees at all levels should be clearly defined in their job descriptions and they should be qualified to fulfill their responsibilities. • Security awareness, including data ownership responsibilities and virus protection requirements, should be part of the employee orientation program, education and training program and performance appraisal process. • A management framework should be established to initiate and control the implementation of information security within the organization. The corporate security function should report to senior management and be held accountable for executing the security plan. • A management approval process for new IT facilities should be established to ensure that the installation of equipment is for a defined business purpose, will provide an adequate level of security protection and will not adversely affect the security of the existing infrastructure. • Information security advisers or focal points should be established and equipped to provide advice on all aspects of information security. They should be allowed direct access to IT and business managers throughout the organization.
  • 7. Manage Security Measures – Guidance, continued • The actual practice of information security should be reviewed independently to provide assurance that organizational practices properly reflect the policy and that they are feasible and effective. • Guidelines for allocation of ownership responsibilities should be established and included in policy statements. Roles and responsibilities of owners should be defined. • Trends and technology developments should be monitored to ensure cost-effective and competitively advantageous use of security technology and to prevent obsolescence. • Third-party evaluation of security policy and architecture should be conducted periodically. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 8. Control 5.2 - Identification, Authentication and Access Objective: The logical access to and use of IT computing resources should be restricted by the implementation of adequate identification, authentication and authorization mechanisms, linking users and resources with access rules. Such mechanisms should prevent unauthorized personnel, dial-up connections and other system (network) entry ports from accessing computer resources and minimize the need for authorized users to use multiple signons. Procedures should also be in place to keep authentication and access mechanisms effective (e.g., regular password changes). Question(s): Do external users have confidence that the system is adequately secure? Have systems and information been protected against unauthorized access or use? Have minimum security requirements for all system components been specified? Is there continued effectiveness of authentication and access mechanisms? Is there appropriate segregation between production, test and development environments? Is there communication to personnel of management’s rights to monitor and inspect all usage of information technology resources, including e-mail, voice communications and all programs and data files? Is all access activity that is not compliant with the organization’s established policies and procedures properly investigated? Guidance: • Policies should be in place to insure that the owners of a system with external users have the responsibility to share appropriate knowledge about the existence and general extent of security measures, so that those external users can be confident that the system is adequately secure. • Systems and information should be protected to prevent unauthorized access or use. • Minimum security requirements should be specified for all operating systems and versions. Operating systems (OS) should be tested to comply with these minimum requirements and tailored where necessary. Compliant OS versions, e.g., OS security parameters based on vendor/organizational standards, should be installed on all systems. Deviations are approved formally after assessment of compensating controls. • Minimum security requirements should be specified for all system components, e.g., software, hardware, communications equipment, etc., and such security is an integral part of the system development lifecycle. • Compliance with security baselines should be reviewed regularly. • Logical access to computing resources should be restricted by implementation of adequate authentication mechanisms for identified users.
  • 9. Identification, Authentication and Access – Guidance, continued • Resources should be protected by access rules, based on adequate identification and authentication of resource users. • A single sign-on should be required for all required resources. • Procedures should be in place to keep authentication and access mechanisms effective. • Following a system failure, users should not be allowed back on the system without reauthentication. • The granting of access, changes to existing access rights and removal of access should be authorized by the appropriate system owner taking into account least privilege, segregation of duties and the level of access required. • Business users should not be granted access to development and test systems except where specifically required for user testing. • The definition of emergency situations and the action that must be taken should be provided by the asset owner, ensuring that individuals to whom emergency access rights can be given are nominated in advance, that emergency rights are removed as soon as the emergency is resolved and that all actions are logged. • Terminals, that for technical or business reasons are protected only by restricting access to the room where they are located, should be physically identified and authenticated by their host computer systems before access is granted. • All systems should require a user identifier and user authentication mechanism to allow access. • Systems should validate the user identifier and user authenticator combination as a pair and reject the logon attempt if it is invalid. Systems should not inform the user which of the two is wrong. • Arrangements involving third-party access to IT facilities should be based on a formal contract containing or referring to all of the necessary security conditions to ensure compliance with security policies and standards. • Access to diagnostic ports should be controlled by an appropriate security mechanism, e.g., a key lock and a procedure, to ensure that these ports are accessible only through arrangements between accountable officials and support personnel. • Personnel should be advised that management reserves the right to monitor and inspect all usage of information technology resources, including e-mail, voice communications and all programs and data files. It should be stressed that this is done to protect privacy and the rights and interests of others. • All access activity that is not compliant with established policies and procedures should be investigated.
  • 10. Identification, Authentication and Access – Guidance, continued • Strong user identification techniques, such as dynamic passwords, challenge response, biometrics and/or public key cryptography, should be used to protect IT resources from inappropriate access by individuals outside the organization. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 11. Control 5.3 – Security of Online Access to Data Objective: In an online IT environment, IT management should implement procedures in line with the security policy that provides access security control based on the individual’s demonstrated need to view, add, change or delete data. Question(s): Is granting of access to data on a need-to-know basis? Is there appropriate segregation between production, test and development environments? Guidance: • Access to data should be granted on a need-to-know basis. • Strict controls should be maintained over access to production libraries. • Production source libraries should be updated only via a formal change process by designated staff with change control responsibilities. • Key security parameters and processes should be identified and their content periodically compared to a protected baseline of authorized contents. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 12. Control 5.4 - User Account Management Objective: Management should establish procedures to ensure timely action relating to requesting, establishing, issuing, suspending and closing of user accounts. A formal approval procedure outlining the data or system owner granting the access privileges should be included. The security of third-party access should be defined contractually and address administration and non-disclosure requirements. Outsourcing arrangements should address the risks, security controls and procedures for information systems and networks in the contract between the parties. Question(s): Is the lifecycle of user accounts properly administered? Is there communication to and acknowledgment by users of the rules with which they need to comply? Guidance: • Procedures should be in place to ensure timely actions in relation to requesting, establishing, issuing, suspending and closing user accounts. All actions should require formal approval. • When employees are given their account, they should be provided with initial or refresher training and awareness on computer security issues. Users should be asked to review a set of rules and regulations for system access. • Users should use quality passwords as determined by the organization’s password guidelines. Quality aspects of passwords include: enforcement of initial password change on first use, appropriate minimum password length, appropriate and enforced frequency of password changes, password checking against list of not- allowed values, e.g., dictionary checking and adequate protection of emergency passwords. • Third-party users should not be provided with user codes or passwords unless they have signed a nondisclosure agreement. Third-party users should be provided with the organization’s security policy and related documents and must sign off that they understand their obligations. • All contracts for outsourcing or contracting address the need for the provider to comply with all security related policies, standards and procedures. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 13. Control 5.5 - Management Review of User Accounts Objective: Management should have a control process in place to review and confirm access rights periodically. Periodic comparison of resources with recorded accountability should be made to help reduce the risk of errors, fraud, misuse or unauthorized alteration. Question(s): Are unauthorized changes to access rights detected in a timely manner? Guidance: • Access rights should be reviewed periodically to confirm they are still as granted and that they correspond to the user’s and the organization’s needs. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 14. Control 5.6 - User Control of User Accounts Objective: Users should systematically control the activity of their proper account(s). Also information mechanisms should be in place to allow them to oversee normal activity as well as to be alerted to unusual activity in a timely manner. Question(s): Is detection of abnormal activity, typically usage of accounts after hours or during holidays/sickness, in a timely manner and reporting of same promptly for formal investigation? Guidance: • User should control the activity of their accounts by reviewing login times. Any abnormal activity should be reported in a timely manner. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 15. Control 5.7 - Security Surveillance Objective: IT security administration should ensure that security activity is logged and any indication of imminent security violation is reported immediately to all who may be concerned, internally and externally, and is acted upon in a timely manner. Question(s): Are attack patterns recognized based on historical data? Is the investigation of security breaches effective and efficient? Are security logs retained as a reliable source of information for investigation of security breaches? Guidance: • There should be a centralized system to allow reporting of security breaches and the investigative actions should be summarized in a log. The importance of the reported items is assessed, appropriately escalated and investigated. • Specific security events that require examination and possible investigation should be identified and included on the audit trail with appropriate information needed to support problem resolution. • No user access to security logs should be allowed. Only programs known to have valid reasons for writing audit records should be allowed to amend audit log files. • A process should be defined to have appropriate security personnel determine whether failed access attempts were genuine mistakes or deliberate attempts to perform an unauthorized function. • Audit trails should be retained for at least six months unless otherwise required by legal, regulatory or any other business needs. • Automated systems or manual processes should be deployed to ensure that any imminent security violation is notified immediately to all who may be concerned, internally and externally, and is acted upon Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- ness: Excellent Very Good Satisfactory Ineffective Not Applicable Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 16. Control 5.8 – Data Classification Objective: Management should implement procedures to ensure that all data are classified in terms of sensitivity by a formal and explicit decision by the data owner according to the data classification scheme. Even data needing “no protection” should require a formal decision to be so designated. Owners should determine disposition and sharing of data, as well as whether and when programs and files are to be maintained, archived or deleted. Evidence of owner approval and data disposition should be maintained. Policies should be defined to support reclassification of information, based on changing sensitivities. The classification scheme should include criteria for managing exchanges of information between organizations, addressing both security and compliance with relevant legislation. Question(s): Are clear security requirements established? Is the appropriateness of the level of security verifiable? Are data classified and labeled accordingly? Do data and system owners have the authority to enforce the protection of assets required by the classification? Guidance: • There should be a clearly articulated process for establishing an owner for each information technology component. • Responsibilities of data owners should be formalized. At a minimum, owners should determine disposition and sharing of data (within the organization or with third parties), as well as whether and when programs and files are to be maintained, archived or deleted. • All data should be classified in terms of sensitivity through a formal and explicit decision made by the data owner according to the data classification scheme. • Reclassification of information, based on changing sensitivities, should be supported by the policies and procedures for data classification. • Tools should be available to help data owners determine the classification of their data security. • Owners should have sufficient authority and knowledge to understand the value of the assets that they own and to balance security needs against cost considerations and other business requirements. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness:
  • 17. Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 18. Control 5.9 – Central Identification and Access Rights Management Objective: Controls are in place to ensure that the identification and access rights of users as well as the identity of system and data ownership are established and managed in a unique and central manner to obtain consistency and efficiency of global access control. Question(s): Are security profiles assigned by the multiple security or system administrators involved consistent? Guidance: • System access should be centrally managed to ensure consistent user profiles for all systems. • Users should be identified and assigned authorizations in a standard and efficient manner, preferably using a centralized user management process and system. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 19. Control 5.10 – Violation and Security Activity Reports Objective: IT security administration should ensure that violation and security activity is logged, reported, reviewed and appropriately escalated on a regular basis to identify and resolve incidents involving unauthorized activity. The logical access to the computer resources accountability information (security and other logs) should be granted based upon the principle of least privilege, or need-to-know. Question(s): Do system abuses and security violations go undetected and security breaches continue for a prolonged period of time? Guidance: • Security-related activity should be logged. • Security logs should be reviewed and exceptions followed up to find root causes. • Appropriate reporting and escalation should be in place. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 20. Control 5.11 –Incident Handling Objective: Management should establish a computer security incident handling capability to address security incidents by providing a centralized platform with sufficient expertise and equipped with rapid and secure communication facilities. Incident management responsibilities and procedures should be established to ensure an appropriate, effective and timely response to security incidents. Question(s): Is sufficient expertise available for the review of security breaches? Is up-to-date information available to effectively counteract identified attacks? Is the number, frequency and importance of security breaches visible to management? Guidance: • Reported security incidents (breaches) should be reviewed promptly by a central team with sufficient expertise to minimize damage and find/eliminate the root cause of the security breach. • Management should be informed of all significant security breaches. • There should be an adequately communicated formal disciplinary process for employees who have allegedly violated security policies and procedures, and employees and contractors should be made aware of this process. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 21. Control 5.12 –Reaccreditation Objective: Management should ensure that reaccreditation of security (e.g., through “tiger teams”) is periodically performed to keep up-to-date the formally approved security level and the acceptance of residual risk. Question(s): Do implemented security controls remain up-to-date as hackers find new ways to breach implemented controls? Are discrepancies between the requirements prescribed by the security design and the implemented security controls noticed in a timely manner? Guidance: • The security design and implemented security controls should be reviewed regularly to ensure that the implementation corresponds to the architecture and to ensure that the architecture is kept up-to-date with advances in security technology. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 22. Control 5.13 – Counter-Party Trust Objective: Control practices should be implemented to verify the authenticity of the counterparty providing electronic instructions or transactions. This can be implemented through trusted exchange of passwords, tokens or cryptographic keys. Question(s): Are certified identities being assigned to hackers or unauthorized users avoided? Guidance: • A registration authority, functioning as a trusted third party, should verify the credentials of a connecting party before transactions can be exchanged. • A certification authority should certify a registered party to ensure counter-party trust. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 23. Control 5.14 – Transaction Authorization Objective: Where appropriate, controls are implemented to provide authenticity of transactions and establish the validity of a user’s claimed identity to the system. This requires use of cryptographic techniques for signing and verifying transactions. Question(s): Does the organization have the capability to verify that business transactions have been originated by authorized individuals or devices? Will the processes not accept any message that is offered for processing as a genuine business transaction unless the transaction has been digitally signed and the signature successfully verified? Guidance: • Cryptographic techniques should be used for signing transactions and verifying signatures to confirm the integrity of the transaction. • The validity of a user’s claimed identity to the system should be established. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 24. Control 5.15 – Nonrepudiation Objective: Where appropriate, transactions cannot be denied by either party and controls are implemented to provide non-repudiation of origin or receipt, proof of submission, and receipt of transactions. This can be implemented through digital signatures, time stamping and trusted third parties, with appropriate policies that take into account relevant regulatory requirements. Question(s): Have the transactions accepted for processing been originated by authorized individuals or devices? Guidance: • Where required, digital signatures should be applied to ensure that data were transmitted by a known source. • Time stamps should be added to transactions and included in the message content that is subject to signature. Time stamps should be based on synchronized clocks and, where appropriate, take into account time zones. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 25. Control 5.16 – Trusted Path Objective: Sensitive transaction data is only exchanged over a trusted path. Sensitive information includes security management information, sensitive transaction data, passwords and cryptographic keys. To achieve this, trusted channels may need to be established using encryption between users, between users and systems, and between systems. Question(s): Can sensitive information be exposed to unauthorized parties? Is proper physical security in place to guarantee the security of media? Guidance: • Sensitive data, e.g., keys, security management information, confidential data and passwords, should be exchanged only over a secure path. This requires encryption as well as appropriate physical protection of the carrier, where possible. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 26. Control 5.17 – Protection of Security Functions Objective: All security related hardware and software should at all times be protected against tampering to maintain their integrity and against disclosure of secret keys. In addition, organizations should keep a low profile about their security design, but should not base their security on the design being secret. Question(s): Is the exposure of such information to unauthorized individuals avoided? Are existing trust relationships with other organizations maintained? Guidance: • All hardware related to the security function should be tamperproof, and guarantees should exist that secret keys cannot be exposed. • The security design should be confidential, but strong enough to resist exposure, in case it would be made available to unauthorized individuals. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 27. Control 5.18 – Cryptographic Key Management Objective: Management should define and implement procedures and protocols to be used for generation, change, revocation, destruction, distribution, certification, storage, entry, use and archiving of cryptographic keys to ensure the protection of keys against modification and unauthorized disclosure. If a key is compromised, management should ensure this information is propagated to any interested party through the use of Certificate Revocation Lists or similar mechanisms. Question(s): Have cryptographic keys been shared with malicious parties? Have registered users’ credentials been verified successfully? Do only authorized users have access to cryptographic keys? Guidance: • Policies and procedures should be in place to organize the generation, change, revocation, destruction, distribution, certification, storage, entry, use and archiving of cryptographic keys, to ensure the protection of keys against modification and unauthorized disclosure. • A proper ceremony with witnesses should be held for the generation or renewal of root keys. • Procedures should be in place to determine when a root key renewal is required. • A certification practices statement (CPS) should be written. The CPS describes the certificate practices that have been implemented in the certification authority (CA), registration authority (RA) and directory in order to comply with the policies for the handling of the various certificate classes as defined in the certificate policy documents. • The CPS version should be mentioned in each certificate issued. • Cryptographic keys should be generated by a trusted third party, after appropriate verification of the requestor’s credentials (registration authority). • Cryptographic keys should be distributed using secure offline mechanisms. • Certification should be required before a secure communication channel, using the cryptographic keys, can be set up. • Keys should be stored in encrypted form, regardless of the storage medium used. • Compromised keys should be revoked as soon as possible and all parties concerned informed of the revocation. Existence: Documented Not Documented Does Not Exist Not Applicable
  • 28. Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 29. Control 5.19 – Malicious Software Prevention, Detection and Correction Objective: Regarding malicious software, such as computer viruses or trojan horses, management should establish a framework of adequate preventative, detective and corrective control measures, and occurrence response and reporting. Business and IT management should ensure that procedures are established across the organization to protect information systems and technology from computer viruses. Procedures should incorporate virus protection, detection, occurrence response and reporting. Question(s): Are systems and data, the integrity and, potentially, the confidentiality of the data available and safeguarded against virus attacks? Is information on new security threats gathered and reviewed by the central security team allowing recognition of new types of attacks and updating of defense systems to counter new types of attacks? Is the unauthorized customization of software or installation of unapproved software avoided? Is the use of illegal software or unsupported versions of legal software avoided? Does the organization have the proper means to demonstrate compliance with license agreements? Guidance: • Virus protection should be active, and virus definition files kept up-to-date. • All executable code should be scanned for viruses before introduction into the internal network. • Procedures for escalation, damage containment and recovery in the event of a computer virus occurrence should be defined, documented and communicated. • Information on new security threats should be reviewed. • Software should be distributed centrally and version and patch-level controls implemented using centralized configuration management. • Unauthorized changes to software, changes that have not gone through the normal development cycle and/or the installation of unapproved software should be prohibited. • Computing platforms should be reviewed for unauthorized software. • Only licensed copies of software should be installed. Software usage should be limited to the allowed number of concurrent users. • Copying licensed software owned by the organization, for personal use, should be prohibited.
  • 30. Malicious Software Prevention, Detection and Correction - Guidance, continued • All incidents should be kept in a central log and tracked until closure. There should be management reporting in place on the number and severity as well as the closure time for such issues. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 31. Control 5.20 – Firewall Architectures and Connections with Public Networks Objective: If connection to the Internet or other public networks exists, adequate firewalls should be operative to protect against denial of services and any unauthorized access to the internal resources; should control any application and infrastructure management flows in both directions; and should protect against denial of service attacks. Question(s): Are unauthorized attempts to access information over the network prevented and detected? Is there no possibility of bypassing the firewall? Is the firewall’s configuration in line with security policy? Is unauthorized inspection or modification of the firewall rule base avoided? Is there proper segregation of networks with different security classifications? Guidance: • Firewall policy should be reviewed/audited and updated at least twice per year (preferably quarterly). A formal process should be used for managing the addition and deletion of firewall rules. In addition, firewall penetration analysis should be performed periodically. • A firewall should be installed, and all traffic should be forced to pass through it. • Only authorized traffic, as defined by the local security policy, should be allowed to pass. The default policy for the firewall for handling inbound traffic should block all packets and connections unless the traffic type and connections are permitted specifically (as opposed to permitting all connections and traffic by default and then blocking specific traffic and connections). • All network traffic dealing with firewall system management should be secured properly. • The firewall itself should be immune to penetration. The firewall architecture should protect itself from attack through active monitoring and pattern recognition. • The firewall architecture should combine protection measures at the application and network level. An in-depth defense should be created by implementing layers of security, as opposed to allowing a firewall to serve as the single/only security layer (e.g., use of a boundary router or separate firewall at the Internet connection to create an external DMZ for web servers and other publicly accessible servers, while using a second firewall to protect internal networks/users). • Firewall platforms should be implemented on systems containing operating system builds with minimal feature sets (i.e., that have been stripped of all unnecessary functionality and hardened for security applications, thereby becoming, in effect, a bastion host); firewalls should never be placed on systems built with all possible installation options. In addition, all operating system patches should be applied in a timely manner.
  • 32. Firewall Architectures and Connections with Public Networks – Guidance, continued • Traffic should be exchanged through the firewall at the application layer only. • The firewall architecture should enforce protocol discontinuity at the transport layer. • Strong authentication should be used for the management of the firewall. • The firewall should hide the structure of the internal network. • The firewall should provide an audit trail of all communications to or through the firewall system and generate alarms when suspicious activity is detected. • Hosts connected to public networks should be located outside the firewall. • Subnetworks, which carry data of different sensitivity levels, should be segregated. • The organization’s firewall environment should be covered by its disaster recovery/continuity of operations plan. • All firewalls should be subject to a day zero backup, backed up immediately prior to production releases, subjected to full rather than incremental backups and employ an internally situated backup mechanism (e.g., tape drive). Firewall backups should not be written to any backup servers located on protected networks to avoid opening a potential security hole to that network. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 33. Control 5.21 – Protection of Electronic Value Objective: Management should protect the continued integrity of all cards or similar physical mechanisms used for authentication or storage of financial or other sensitive information, taking into consideration the related facilities, devices, employees and validation methods used. Question(s): Is the confidentiality, availability and integrity of information ensured? Guidance: • The integrity of all data should be guaranteed by controlling changes through the use of access control mechanisms as well as monitoring for unauthorized changes. • Adequate physical security should protect authentication devices and storage/processing facilities. Existence: Documented Not Documented Does Not Exist Not Applicable Performanc e/Effective- Excellent Very Good Satisfactory Ineffective Not Applicable ness: Person/Area of Responsi- bility: Explanation/ Description/Documentation Monitoring Documenta- tion of Control(s) & Monitoring Activities:
  • 34. Michigan Department of Information Technology CONTROL SELF-ASSESSMENT QUESTIONNAIRE Listing and Certification of Outcome Please list any potential control issues below: Potential Control Issue Recommended Action Implementation Date ------------------------------------------------------------------------------------------------------------------------------ This certifies that I have completed the “Delivery & Support – Ensure System Security” Control Self-Assessment Questionnaire, having answered all questions to the best of my knowledge and ability. Prepared by: _________________________ Reviewed by: _________________________ Printed Name: ________________________ Printed Name: _________________________ Title: _________________________ Title: _________________________ Date: _________________________ Date: _________________________

×