The CISA Prep Guide Mastering the Certified Information Systems Auditor Exam phần 5 pptx

would or that a jury would accept the argument. It will be very important as a result of this and other concerns with PKI to ask many hard questions up front as to what the purpose and intentions are for the PKI installation and what the business problems are that are to be solved by its implemen- tation. If they are authentication based, your process for review will differ from a review intended to prove protected transmissions through encryp- tion methodologies. Biometric Access Controls Biometrics authentication continues to mature, but it is still not readily accepted in commercial production for an audit review. The human parts used to validate identity include face recognition, iris scanning, eye retina geometry scanning, hand geometry scanning, fingerprint mapping and matching, keystroke cadence matching, voice recognition, and probably some sort of body fluid matching, if you look hard enough. The concern over the usefulness of such metrics is related to the matching process of the registered sample pattern to the live person. The system approximates the real specimen, thus error is introduced into the process. Because humans are dynamic in nature, the source biometric changes somewhat over time. A moving target and an approximation of a sample captured at some time in the past force the matching process to accept a certain amount of error in order to be useful at all. False positive acceptance and false negative rejec- tion will need to be measured as part of your evaluation to determine how well the process works and whether the error acceptance ranges introduce unacceptable risk. The initial expectation is that these biometric solutions are used when extraordinary controls are required, so high error rates are less acceptable than they would be under less demanding conditions. On top of that, there will always be some people that the process will just not work for, such as the handicapped, for example. Therefore, alternative processes will need to be present and working as viable alternatives that add to the evaluation and review process as well as to the management and overhead for biometric solutions of the organization. Privacy of the registered information related to the user’s biometrics will be a priority for the users and may be an object of your review. Strong physical and logical security measures, along with strict disposal and data sharing criteria, also will need to be examined. Reviewing the controls on the data repository also is required. You will want to view this authentication device as a potential single point of failure and explore what the contingency plans are for unavail- ability or the disruption of its process. Look for disaster recovery alterna- tives if access dependency is placed on this authentication method. The 222 Chapter 4 registration process will be interesting to you because it is the point at which the identity is established and linked to the biometric that will be the match for the presented identity going forward. The records of identity registration and any problems encountered during this process also should be reviewed. Attention should be given to the registration process so that the gathered samples have integrity. Evaluation of a biometric authentica- tion process will likely include a review of the practical success of the process in performing the intended function and the acceptance of this method of authentication by the user population at large. Opportunities to circumvent the control and complaints about acceptance or rejection rates of the system should be investigated and reviewed for remediation and follow-up processes along with the related documentation. Change control procedures that protect the established benchmark measurements will lead to a better control process overall and more user satisfaction. All of the other standard IS process review routines related to SDLC, Human Resources, KPIs, and planning, maintenance, and problem management apply here as always. Network User Access Evaluation of the controls over network access could mean either control over being able to get on the network as a network user or being able to modify the network as a network administrator. Network device access will be addressed in the discussion of network infrastructure security. The network user access, however, is a base privilege of the application users for some configurations and must be successfully negotiated before the user can gain access to the application servers and other services on the network such as remote access devices, Web services, or printers and file servers. Network user access is controlled by the controls of the network operating system, typically Microsoft NT domain controllers, Microsoft active directory services, or a Novell network operating system, of a simi- lar domain control scheme. Account administration for these accounts will require a basic identity management system that you will usually find tied to the production application account management process. Quite often, email services also will be an attribute of the base access to an IS organiza- tion’s network infrastructure and the related services it provides. Your assessment of this scenario will follow the review for account administra- tion processes outlined previously. There also may be additional items to review that are unique to the services and privileges available to a network user that are not covered in an application account administration review, which will need to be identified and included in your testing and analysis steps. Protection of Information Assets 223 Identifying the services that are available to a user is a basic step for assessing the access control of any process, application, or system. Once you have determined what the possible ranges of the permissions are, you will want to identify any natural groupings of these services that are offered to users as a profile. Categorization of these services by their pro- files, if possible, will enable you to better understand the next review phase. This next phase is where you match users up to the profiles and determine how the rights to be granted these profiles are decided upon, what job functions deserve which access profiles, and where the special cases and exceptions are. Any access that requires the additional down- stream access granularity to be determined before the access can be prop- erly managed on the downstream device or service will warrant an investigation. How this information and the request for it gets passed along in a timely manner to meet the needs of the business making the request for access will need to be investigated. Feedback mechanisms, turnaround time, approval process flows, and record keeping will all be on your short list of control objectives in this assessment. Information Security Architecture Information security architecture is a concept that covers all of the security- related items discussed in this chapter tied into a strategy that is cohesive and considerate of all of the risks and controls. Security architecture has to be a consideration that is integrated with the functionality of an infrastruc- ture during all design phases in order for it to best serve the needs of the business and system users. An evaluation of security architecture will include a review of the risk assessment methodology used to baseline the current state and will analyze the best practices for the business against this current state of the assessment to determine any gaps that need addressing. A security architecture that recognizes the business risks and implements countermeasures, processes, and procedures that provides appropriate controls for those risks is what you will be looking for in this assessment. Documentation of the data classifications, sensitive data loca- tions, and inherent risks should be available to show that the architect understands what it is they are trying to protect. Integration of the various solutions for securing the environment that encompass host-based as well as network-based and application-based controls should be found. A design process should exist that ensures the chosen tools work well together, compliment each others strengths, and compensate for each other’s weaknesses, to provide a security in-depth solution that stands up well to the task of providing the level of security and protection required to 224 Chapter 4 meet the businesses needs. Enterprise security architecture will separate information into logical network zones to protect the data and to isolate users based on the need to know and the security classification of the data. Because security tends to seek the least common denominator, grouping the servers into zones enables a designer to limit this compromise of secu- rity to discreet levels, which can still meet the needs of the business while not watering down the security to unacceptable levels for more sensitive applications. The design will, therefore, focus on the perimeter lines that delineate the break between these zones and ensure that integrity is main- tained and the rules for crossing that border in or out are well understood and preserved. Security architecture will provide for standard security ser- vices of authentication, authorization, auditing, and intrusion detection as part of this border patrol and will be designed with the best practices, worst case analysis, and the business risks in mind. Security Plans and Compliance An excellent benchmark of a good security process is to have security plans defined and documented for each and every system that makes up the total IS organization processing infrastructure. This includes not only infrastructure-like systems and networks but also applications and their interfaces. The security plan for a system or infrastructure provides an overview of the security controls as well as documents the business processes and expected performance and behavior characteristics of the process and its users. It should be the basis for the review and approval of a system’s security prior to implementing it into the processing environ- ment. Evaluation of a security plan design and approval process will assess the processes of gathering, documenting, reviewing, and maintaining of all the security plans. It also will include an evaluation of how well these plans cover the actual equipment in place, the extent to which these plans reflect the current configurations, and an inventory match of the systems in the environment to those on record with the security plans. Exceptions will need to be examined for risk exposure and commented on as appropriate. Security plans should explain the business process and the data quality. These plans should identify all of the people involved in the target system: the systems support organization, the owners, the data stewards, and the user population. Enough information about each person or group should be provided so that they can be identified, their responsibilities and accountabilities clearly documented, and so that they can be contacted and communicated with should the need arise when availability or compro- mise issues related to this system occurs. Understanding the business pur- poses of the process that this system supports, who the typical users are, Protection of Information Assets 225 and what other processes may be dependant upon this one will give the operations and security staff a sense of how important the system is when referring to the security plan. It also will tell them what to do when there is a problem related to the proper functioning of this system. An evaluation will first need to look at the policy requirements for pro- ducing and maintaining security plans. This management process should be a required step in the formal implementation of any SDLC methodol- ogy. Because systems and processes change over time, part of the change control process also should have a requirement to update and seek renewed approval of the security plan when changes are significant enough to warrant such an action. Substantial security changes, function- ality modifications, or changes in support or authorization personnel are some examples where the security plan should be revised and resubmit- ted. Subsequent procedures will be required on the types of documenta- tion to include in a security plan, possibly through some templates that will guide the plan’s author through the process of building and gaining approval for it. In this way, examples can be provided and a standard for- mat can be used, facilitating an easier review and consistent reference of the documentation. Risk assessments are an important part of understanding the system security needs and the residual risks related to the countermeasures that may be deployed to mitigate unacceptable risks. Evidence of this risk iden- tification process and the subsequent identification of acceptable levels of controls should be a required part of the documentation. Differences between the acceptable level of control and any compromise position taken during the actual implementation of the system covered by the plan also should be noted and approved by the data and systems owners as well as by the security management. The procedure should require the review and approval of both the secu- rity manager and the businesses owner so all are in agreement that the risks and controls are fairly represented both in need and delivery against that need. Templates and procedures for the security plans should require that all controls are documented and explained. This includes management con- trols, technical controls, and operational controls. Diagrams and explana- tions should be required that clearly draw the system’s boundaries and walk the reader through the transactions and process flow that are performed by the system. Maintenance requirements, such as update histories and processes for a periodic review of the existing security plans, should be pro- vided for as part of the routine maintenance processes of the security plans. Data used by or passing through this system should be identified and the identification of its security classification should be a requirement for inclusion in the security plan documentation. The owners of that data 226 Chapter 4 should be noted and their approval of the security controls in place on this system needs to be evidenced through their concurrence with the plan as part of the documentation. The security plan documentation should be part of the evidence trail that tracks the data flow and ensures that the con- trol of highly classified data is managed as intended by the data owner. Any regulatory restrictions or legal compliance requirements that need to be observed and maintained by this system should be documented, along with proof that the control requirements have been satisfied. The support for the system and its functional components should be documented, along with the security baseline hardening procedures per- formed on each of the components and subsets of the systems that make up a single security plan. Guidance on what constitutes a single plan and what needs to be viewed as requiring separate plans should be determined in advance and provided as part of the procedural and authoring guidance documentation. Any external connection points and interfaces should be identified, along with any processing dependencies and expectations for systems upstream and downstream in the overall process. The data type, format, and quality should be noted at each entrance and exit point of the defined system’s boundary. This is especially important for dial up and other external connection dependencies. Systems should be labeled and depicted in the documentation in such a way that the operations staff can walk up to them and place their hands on them according to the documentation provided in the security plan. Nam- ing conventions, equipment layouts, and overall configuration diagrams will help these readers understand what is supposed to be happening and will identify any differences between that and what they are currently observing. This may become necessary should a security breach in progress need the most direct of control measures to be applied, such as pulling the plug. Security plans are living documents by necessity. As patches get applied and operating parameters change the expected controls, the security plan will need to be updated. Knowing what controls were in place historically at a point in time for a forensic examination, for example, makes a chrono- logical change control record of the plan a required part of the documenta- tion. You should be able to tie all major system upgrades and security changes from your review of the change control process back to the secu- rity plan, which ensures that timely updates are occurring to enable the proper reaction and support for the system by the security and operations staff. The processes used for the development, testing, and review of the users’ needs may be helpful in understanding the limitations and problems with the system, should they arise in daily operations. Consideration also should be given to including this information in the security plan. Protection of Information Assets 227 You will want to assess the security plan requirements in the environ- ment you are evaluating against these best practices and use your best judgment to determine whether the gaps found are material in nature or significant enough to warrant comment resulting from your review. How- ever, having good requirements for security and system documentation is only part of the evaluation process. The hardest part of the procedures and documentation for any IS organization is to actually produce the written documents that are required and to maintain them. This takes a diligence and discipline that often is lost in today’s short business cycles, rapid design methodologies, and time to market deadline shrinkage. You will want to sample the actual security plans on file and review them for the proper content, authorization, and approvals. Evaluate the content against the standards requirements to determine if they are being built and main- tained properly. As mentioned previously, you may want to compare the plan’s currency with the change control documentation for the same sys- tem to see how well these changes are being updated. Finally, actual secu- rity testing of the system and a comparison of the results to the plan documentation may be warranted in high-risk systems or in situations where your objectives require a high level of confidence that this informa- tion is being maintained. The final part of this evaluation will be to reconcile the population of security plans to the population of systems that require them. You may want to identify the process for managing these inventories and reconcile them periodically as a way to ensure that this is an ongoing process to be actively managed. Review and Accreditation of Systems In order for an information system to adequately meet the needs of a busi- ness, the business’ management and data ownership must approve of the system and agree that its implementation is capable of satisfying the needs of the business. This approval is the basis for all action taken on the busi- ness’ behalf. The business leaders understand their risks, their tolerance to accept risk, and their accountabilities to the clients and stakeholders better than anyone else. They must, therefore, ultimately approve the systems that will be performing functions in support of their business. Before com- puters, these businesses hired a labor force to produce those same outputs and computations who were responsible to ensure that the output was adequate. Using an information system to perform the same process is no different; the business leaders are still responsible for the quality and quan- tity of the output. If you hire a poorly qualified subcontractor to produce 228 Chapter 4 for you and they do not perform to your customer’s expectations, it is your responsibility to address the problem, not your customers. If the computer system you commission to perform a service for your business does not meet the data control expectations of confidentiality, integrity, or availabil- ity, the business is accountable for these errors in the eyes of the customer. Any business that relies on a system or third party without doing their homework and approving the process in advance gets what they deserve. These are the root reasons to test and approve system implementations and even changes to existing systems, for that matter. Relying on systems design and operations staff to test and approve a system without any busi- ness oversight is akin to letting the fox watch the chicken coop. Testing and accreditation must be performed by a knowledgeable party that represents the business and data owner’s interests. When evaluating this process for the business client, the hardest part may be getting this point about responsibility for testing and approval across to them. They do not understand systems and see the development and systems support staff as the only knowledgeable party in this matter that they know. Certainly, several vendors will insist that others are not qualified to judge their work and test it sufficiently. You should expect to see a validation process in place that will ensure that the design criteria and functional requirements are met for major system deployments and upgrades that are being turned over to production for use. Your evaluation should assess the processes used for this systems testing to ensure that the methodology is sound and that the results are documented fairly to meet the needs, which were set up as qualifying criteria before the testing was conducted. Security testing is part of that assessment. It should cover basic best practice security controls, along with ensuring that policies and standards are adequately met, regulatory issues are addressed in the design and accounted for in the testing results, and that the testing bears out the qual- ity of controls necessary to meet the needs of the business. Security testing can be very complex and encompass any or all of the security- and control- related issues that are only touched upon in this chapter. All of this will naturally depend on the risk that needs to be protected against, which is another reason why the scope of the testing must be a business manage- ment decision. If the SDLC process used for development identifies the range of secu- rity and control risks and the possible mitigants from in the analysis phase, as it should have, your assessment is merely a matter of checking to see that those items were satisfactorily addressed during testing and perform- ing some spot reviews of some of the results in order to validate the Protection of Information Assets 229 process. Security testing may be as involved as performing penetration testing and rigorous attack processes, testing code and configurations to see if they can be compromised. But in a business environment, this is not usually the case. Regardless of the level of testing, which will hopefully be a risk-based decision, there is an absolute need for evidencing the spon- sor’s approval for the final product so that the risk can appropriately be transferred back to the business accountable for the process. Host-Based Security At the server or information system component level, there are lots of security-related efforts required to keep a tight control on the information assets. This area frequently receives support attention from systems administrators who tend to react to operating system choices and their rel- ative usefulness and popularity with religions fervor. However, except for the functional performance nuances such as scalability, interoperability, and applicability to special situations, these hosts can be seen as relatively similar from a risk and control perspective. When evaluating host-based security, you will need to understand the business process that is to be accomplished by the device just as you would for all other review processes you undertake. If you do not know where you are going, you will not know when you have reached your goal. Each host will have pri- mary tasks that was put in place to accomplish, although there may be many functions that a host device is tasked to support and perform. Your evaluation of the operations and maintenance of this host device will be greatly simplified if fewer purposes or services are supported on it. For every function or task that a host is expected to accommodate, there are certain controls that will govern that transaction or task. Services will be required from this host and the permissions for access, the execution of the process, and the manipulation of the code and data are a natural part of each isolatable process or function. The more functional requirements a server has, the better the chance that one of the processes required services or permission settings will be in direct conflict with the successful mission completion of an adjacent process or task requirement on the same server. Some of this is unavoidable, of course. Some of it also can be isolated through logical partitioning and virtual machine instances. At the operat- ing system and hardware layer, the compromise required to have these processes coexist in harmony may or may not create other sets of issues. Your evaluation of host-based security controls and processes will involve the identification of each service or process task required of each device or host in the inventory encompassing your review objective’s 230 Chapter 4 scope. You should understand what services, configuration settings, and access permissions are required by each service and look for a potential conflict of the various processes or services offered on a particular device or conflicting control requirements that result from coexistent services. You then will need to review the configuration settings and services open and permitted on the device and perform a gap analysis compared to a leading practice configuration. You should question any open ports or services running on the devices that are not explicitly needed to perform the busi- ness functions being supported. Explore the impact of turning off each unnecessary service and understand what possible needs it may serve or the conflicts that may arise. Minimum Security Baselines (MSBs) Setting the services and security settings to the minimum necessary needed to perform the required functionality, along with configuring the device for optimum security control, while still enabling the business func- tions to operate unimpeded, defines the minimum security baseline (MSB) for that device. This baseline setting process will include ■■ Ensuring that all code is up-to-date and any available security patches for the operating system have been tested and applied with the required business system configuration, providing for the ongo- ing maintenance of proper security levels ■■ Ensuring that all unnecessary services are turned off and otherwise disabled, thus minimizing the functionality of the operating system to only the processes required for the applications and functions it is directly supporting ■■ Resetting any default passwords where possible to avoid opportuni- ties for compromise; restricting guest and anonymous access; and renaming default accounts were possible, to deter use ■■ Using nonstandard ports to hide easily compromised services and communications where possible ■■ Using encryption to protect sensitive data at rest and in transit wherever practical ■■ Turning on the required level of logging and audit trail capturing to evidence any unauthorized activity ■■ Providing for the routine monitoring and analysis of log and audit information Protection of Information Assets 231 [...]... where the user, sitting inside the secure network, accesses the services on the untrusted Internet by using the proxy server as their surrogate and making the request for them They are protected from the untrustworthy network segment through this isolation— their address is not part of the actual request for service made to the provider From the service provider on the Internet, for example, all they... exchanging this secret must be handled either through some other trusted path or be encrypted itself The larger the key or secret, the stronger the protection can be but the more computationally intensive the process is to process the data The better the chance that the key is only known by the sender and receiver and the shorter its life cycle is, the less need there is for strong encryption solutions... executive holding the laptop writes the key on a yellow sticky inside the device, what has effectively been protected? Encryption during the transmission of data is further complicated by the fact that the sending and receiving ends of the “encrypted pipe” need to know the same secret in order to encrypt and decrypt the data flowing between them The fact that the line between these ends is untrustworthy (or... (NICs) The one side does not even know about the other side, thus making it impossible to “see” through to the other side unless the device in the DMZ is compromised Dropping off files or requests for information in a DMZ for pick up or handling from the other side is primarily how the process is designed to function Your evaluation of the DMZ and related devices will include an assessment of the firewall(s)... the proxy makes the request to the business logic layer and retrieves the response on the requestor’s behalf Control logic can again be used to ensure that the user is identified and meets the predetermined business criteria for getting the results for which they are authorized Evaluation of the controls and objectives of a proxy implementation will be straightforward Once you know the process of the. .. understand the data controls that are to be implemented with the proxy and be able to review the proxy configuration to get a firsthand look at how the design is intended to secure the transactions and to separate the users from the requested services You must assess whether the process works as designed and how well the design mitigates the risks that it has been put in place to control Look around the DMZ... going on at the desktop presentation layer can slow down the user’s experience to the point where work cannot be performed at all If there is not enough access on a worker’s desktop to the programs and icon they need to perform the job, they cannot fulfill their mission Decisions about letting users install software on their own desktops will need to be weighed against the risks of doing so and the potential... occur throughout the process flow of a connected session Stateful inspection firewalls remember session information and track their activity maintaining the state as the session changes during its lifetime Proxies filter and separate requests inbound to them and forward requests going outbound from them, thereby segregating the connection from going all the way through the network to the next network... used extensively on the Internet to maintain trust and confidentiality between two locations There is not much to evaluating an SSL process because of the standard nature of the process Unless the systems have been compromised and tampered with, a session is negotiated and the port for the traffic is moved to the secure channel and the two servers go about their business using the negotiated key Digital... to identify the services and data available and the control requirements for each of them, and then ensure that this is indeed the level of control being provided in the live configuration Because the software often is not designed 251 252 Chapter 4 with security as default criteria, there can be many hidden scenarios for exploiting access that even the designers were not aware of when the software . evaluation of how well these plans cover the actual equipment in place, the extent to which these plans reflect the current configurations, and an inventory match of the systems in the environment to. plans should identify all of the people involved in the target system: the systems support organization, the owners, the data stewards, and the user population. Enough information about each person. look hard enough. The concern over the usefulness of such metrics is related to the matching process of the registered sample pattern to the live person. The system approximates the real specimen,