Event ID: 2053726 Event Started: 11/28/2012 8:00:00 PM ---------- Please stand by for realtime captions. >> [Captioner on hold waiitng for event to begin] >> The webinar will begin shortly, please remain on the line >> Good afternoon, everybody. We will be starting the webinar shortly. >> Good afternoon, everybody. Welcome to the third in a series of webinars on federal risk and authorization management program. We appreciate you taking the time to view this webinar. We are curious to see what your questions are and also to we are gratified to see how many people are interested in the FedRAMP program >> I'd like to start with a definition of FedRAMP . I think it is a good way to set the stage. We will be answering today's question about what distinguishing a good security control system and what should you do do in preparing the description ? >> A well-documented system security plan or SSP can make the difference between moving through the FedRAMP process at a decent clip to having lots and lots of rework, lots of time as you progress along the FedRAMP process >> I think this is one of the key documents that is part of the program, it is very important that it is complete, thorough and understandable. The goal of today is to answer and address some of the problems come up questions and clarification that may be needed as you move forward and preparing your System Security Plan >> Before we begin, I want to remind you that you should submit your questions as they arrive, members of my office will be looking at the questions and they will be answering them as time allows >> If there are questions that we do not have time to get to, we will answer them later in a broadcast or a message to all of the people who signed up for the webinar. We usually do it on a spreadsheet rather than trying to in addition, we will be releasing a set of the slides at the completion of the webinar >> Let's talk about the system security plan overview. The System Security Plan is one of the first documents that you submit in the FedRAMP process and it is a global view of how the system is structured and the personnel are who are responsible for the security of the system. It is important that this be clear and it be understandable by the ISS so staff who are reviewing your submission. The SSP should provide a distinction of the agency or customer is responsible for a particular control. Who is going to be the one who is responsible for implementing and monitoring that control ? some controls can be shared >> The SSP should apply provide how your system is architected and how it implements NRST SP 800 53. You should describe the controls in place and distinguish them from controls in the future. Demonstrate that the proffered safeguards are in place to protect data contained and transmitted by the system. The goal is to document how you are ensuring the security of the information that is contained in the system. The system security plan is one of the first documents that we look at and it is some of your first impressions of you. It gives us enough information so that we can understand how the system works, what the system boundaries are, and what the supporting infrastructure is. It should show the interconnections to other systems, it should have network diagrams that explain how the controls are implemented. Putting together a well-documented System Security Plan can save you a lot of time in moving through the process >> Why such a long document ? before you start it is 352 pages long. We realize the template is long, however, we have designed a format that ensures that we have the information that we need to review your system. It is a document that needs to be standalone and should be filled out with enough detail for any reviewer to understand how your system meets the security controls requirement. We develop this system security plan template with members from the joint authorization board staff, it was not just us thinking of this, but we had input from and including GSA, DHS, DOJ as well as other interested security personnel. It has had a lot of review, the template makes you meet federal security standards. We are rooted and grounded in official publications >> It will take a fair amount of time to complete it. We need the proper level of detail and we have tried to guide you to that level of detail with that template itself. We are here to assist you with the completion of the template. As you begin, you will be assigned an ISS so who will be working with you to make sure that the document that you submit is submission sufficient for our review >> One should get a Fed ramp it should save time, money, and resources for you and your agency client. A high-level SSP document organization is really in three parts, the initial section, the scope and the purpose and structure of the system in terms of software and hardware, the boundary of the system and connections with other systems outside of the boundaries >> Section 2 contains the actual control implementation description that covers 17 control families and low and moderate FedRAMP baseline . Is each control has a summary control table as part of the sum template for you to complete >> The third section is an appendix of supporting documentation that is submitted with SSP , it includes the information security policy, user guide, authentication worksheet, policy special analyses, privacy impact assessment, rules of behavior and other documents that are specified in the template. I webinar will be structured around these three areas. >> Now I will turn it over to Matt Goodrich was the project manager who will talk about the first section, which is a description of the system >> Sections 1 through 11 in the system security plan defined the scope of the system and provide the ISSO of system implementation, purpose and architecture >> In section 1 of the system security plan, you need to provide basic system information. Use the package ID that was assigned to your system when you feel the FedRAMP initiation form >> In section 2, you will need to provide the security impact categorization. The information type for confidentiality integrity and availability of the system >> The categorization should be consistent with those found in FIPS application 199, which can be downloaded from this website. It defines the potential impact of organization should there be a breach in security. 99 analysis should be performed with respect to the service provider system were customer data to select the information type of the system. Based on your security impact analysis, provide a high watermark of low, moderate or high for the various information types in terms of confidentiality, integrity, and availability >> You will also need to record the results of an E authentication analysis in section 2.3 of the system security plan. You perform this using the eat authentication template that is provided by FedRAMP . This template helps you to select the proper authorization solution for the system and it is used to to find the required authentication level >> The requirement for the eat authentication analysis is based on OMB memo 04 04 04 04E authentication guidance for federal agency. It requires that Federal information system owners determined the system electronic authentication requirements to minimize the potential impact of authentication errors. You may want to refer to the OMB memo for more information >> In the next sections you will list the system owner, designated contact and assignment of security responsibilities. The system owner is a person and your organization that will be the primary point of contact for the system. The system owner is the primary person within your organization who is responsible for the accuracy of the information and the in the SSP . Other designated contacts, management and technical contacts should be put in the tables in the template >> In section number six, you need to provide contact information for the person from your organization who is responsible for overseeing the security of your system. The FedRAMP will provide you with information to put in this table >> The next few sections of the system security plan ask you to describe the system in terms of its operating status, cloud service model and whether or not you have leveraged any other provisional authorization when building your system >> For example, a CST offering a platform service on top of an infrastructure for service provider. The platform cloud service provider will inherit many of the infrastructure of service provider control >> Now Laura Taylor will discuss the system boundaries and the control and limitation of the SSP >> In section 9, the system security plan asks for specific information on the purpose and function of the system architecture. When the SSP ask for the purpose and function of the system, we are asking for a general description of how the system, who can use it and what the main features are. In defining the types of users, we are looking to find out actual user roles and see the defined privileges of the users in the system such as, systems administrator, Web server administrator, database administrator etc. >> We are not looking for employee titles or names of specific users. What we are looking for is to have you describe if each user is internal or external, the sensitivity level of their position, and authorized functions and privileges for their role. >> The next part of this section asked you to define your system boundaries. You need to be able to describe the boundaries so you can define where the system begins and ends. When discussing boundaries, be sure to include information on how different tenants are separated from each other in a multitenant environment. Be sure to describe all the components, configurations within the boundaries and include components for protecting boundaries such as firewalls, forced protocols and services that are filtered in and out of the boundaries >> Discuss the live migration strategy for virtual machines so that we can understand if those migrations are occurring within the boundaries. The descriptions of the components within the boundary should include storage solutions that are implemented by the system, for example, direct, attached storage, or storage within the network and where alert fire channel is implement. Naming can be important here and we recommend keeping the naming conventions consistent in the description of the boundary and throughout the entire System Security Plan . Using your own internal naming conventions is a good idea because when you are referring to them in various reference documents, these names will be familiar to everybody in your organization and it is a good way to avoid any confusion about naming >> The description of the boundary continues in section 9.4 of the system security plan you to provide network diagrams to describe the system architecture. Make sure that the diagram include all the components in the description of the boundary and that the naming convention are also consistent. Label of the components of the diagram, the diagram should include hostname, servers, authentication server, firewalls, routers, switches, databases, major applications, operating systems, connectivity providers, Internet service provider and network members >> System 10 asked for a detailed technical description of the system environment. This also asked for detailed inventories of hardware, software, network devices and components and port protocol and services. It is key that these inventories are detailed and comprehensive. Missing components are not providing inventory is a showstopper during the review of your SSP . Make sure that the names used for the components are consistent with the boundary description and the network diagram >> Section 10 also asked to provide a data flow diagram which maps the flow of data in and out of the boundaries. While this diagram focuses on illustrating the flow of data, rather than the network typology, son network components of the system need to be included in order to illustrate the direction on how the network traffic flows in and out of the system. >> Section 13 is where you complete the actual security control and limitation description for your system. The system security plan template includes the stated missed control, including the control and enhancements and security control summary information that CSP's need to fill out to detail how they meet the requirements of that control including all the control enhancements. Each control and the control enhancements has a security control summary information table. >> First you will have to name the responsible role for the control. This is the staff member responsible for maintaining and implementing the control. This is not a person's name, but a role identified with that responsibility, for example, system engineer or systems administrator. The role must align with stated roles and positions within the company. >> Next, we ask for a parameter for that control, usually a frequency, such as number of days or length of time. Then we ask for the implementation status of the control. This is where you describe whether it is a control that is in place, partially implemented, alternative or compensating control or if the control is actually not implemented at all. >> You are going to next describe the control origination by selecting the proper box in the template. This information states who has the responsibility for implementing, operating and managing the control. This responsibility can be assigned to CSP, customer, or it can be a shared responsibility. Is important to describe where the control originates from so that it is clear who is responsible to implement, manage, and monitor the control. >> The system security plan control origination tradable table provides definitions for defying that control origination. The table includes control origination, name, name and conventions, exact description, and an example. The service provider corporate reports reporters to a control that originates within the corporate network. This service provider system specific refers to a control that is specific to a reticular system at the CSP, but the control is not part of the standard corporate controls >> The service provider hybrid refers to a control that makes use of corporate controls and additional controls that are specific to a particular system you are describing >> Configured by customer refers to a control where the customer needs to apply a configuration in order to meet the control requirement., For example, this might be something that you select from a pulldown menu or a radio button >> Provided by customer refers to a control where the customer needs to provide additional hardware or software in order to meet the control requirement >> Shared refers to a control that is managed and implemented partially by the CSP and partially by the customer >> Inherited from a pre-existing provisional authorization refers to a control that is inherited from another CSP system that has already received a provisional authorization >> None of the one controls, a C1, FC one, can be inherited as these controls our policy controls, policies and procedures and every CSP needs to have their own set of policies and procedures >> Finally, you need to describe what the solution is and how it is implemented. This is where you need to provide enough detail to adequately allow reviewers to understand exactly what it is that you are doing and how you meet this security control requirement by providing enough information so an assessor will understand what it is that you're doing. If you are using a commercial office the shelf product, we want you to name the product, provide the version number, and briefly describe how it works >> Simply stating that you meet the requirements in a one sentence description, will not be enough information >> The SSP is a document that requires an eye for detail and something that you are going to have to be sure is consistent with all the other documents in your security package. >> A few small mistakes can can create a lot of questions when you are going through the review process and we are hoping to avoid the FedRAMP ISSO having to ask you a lot of follow-up questions, which will slow things down >> There is an easy mistakes to avoid prior to submitting your SSP >> Make sure that it includes a complete hardware and software inventory. Make sure that the components of the system are consistent with what is found in the inventory. There also should be correlation between the items on your network map and the items found in the hardware and software inventory. If you're naming items in your inventory, what the FedRAMP ISSO are going to be looking for, I the same items on your network map ? >> If you include references to other documents, include the official document name of any other documents, the version number and its publication date >> A control that does not apply your system should not be described as being implemented in the system >> Nonapplicable controls in the template should not be left blank or removed, simply write not applicable and prepare a justification statement of why that requirement is not applicable in this case >> Failing to review responses that you have written can sometimes lead you to erroneously cut and paste lines from other documents you may have created that might not actually apply to these particular controls in your system security plan >> If you are pulling some of the information from older documents, make sure to review the response before you paste it into the FedRAMP SSP template so you can double check that you have pasted the response in the correct spot. In some cases we have received System Security Plan where the cut and paste answer did not address the control or contained out-of-date information. Providing very short descriptions in a control requirement response, rarely is enough information. Do not simply restate the requirements, we already know what the requirements are, you need to demonstrate how the control is implemented in your system. Talk about how the control works, it is okay to paste in screenshots or diagrams, if that makes it easier to explain the control. You can control based in snapshots of log files or various AU controls. Make sure the length of the response is adequate to provide enough detail to properly answer the control requirement >> Now I'm going to talk about how you might need to modify the SSP . We have to designed the SSP to capture the requirements, but some of them may need to be tweaked to assist in documenting their system. Is acceptable to add new sections to SSP if it allows you to better describe your system. You can add sections, but you cannot remove any required sections in the template >> You want to make sure to provide sensitivity markings on the cover page and the footer of each document. You may change the existing sensitivity marking in any template to match or official company sensitivity nomenclature if it is different than on the template. Sensitivity markings may be placed in the document that you feel requires sensitivity labeling >> There are various supporting documents that should accompany your submission of the SSP >> You will need to provide implementation information security policy document that governs your system. >> You'll also need to submit a user guide. This is the document that you will give to your agency customers to describe how to use the system >> The rules of behavior defined the system user responsibility and expected behaviors with regard to information >> A sample rules of behavior template is available on tran1.com >> The IT contingency plan is used to define and describe measures to recover information system services after a disruption >> Your IT contingency plan should demonstrate that you have the capability to backup and restore systems to limit the effects of any disaster and the subsequent recovery efforts >> The configuration management plan describes how you manage and track changes to your system. The configure it configuration management plan should be consistent with publication 800 128 >> Your instant response plan documents how incidents are detected, reported and how they are escalated. It should include time frames, points of contact and how incidents are handled and remediated. The incidence response plan should be consistent with special publication 800 61 >> A privacy threshold analysis helps determine if a privacy impact assessment is required. This document assesses what personally identifiable information is captured and if it is being properly safeguarded >> What are the keys to structuring the response to ensure that your documentation meets the proper level of detail required ? >> All documents will be reviewed for completed. Make sure that all sections are complete in every requirement is addressed. Ensure the response is and details are consistent. Other federal documents are cross checked with what is in the SSP. Make sure naming conventions, control limitations and components listed are consistent across all documents >> Supporting documents such as the incidence response plan or configuration management plan must be delivered with the system security plan. Make sure your references when supporting documentation as part of the response describing how you meet requirements >> Provide details of any relevant corporate policy, rules of behavior, waivers and other documents within that description >> This includes naming providing a reference of where to find it in the supporting document and how to find the relevant section referenced in the response >> Following criteria will help you ensure that your responses meet the requirement >> What is the document solution, who is the responsible party for the solution management ? when is the solution reviewed or monitored for effectiveness ? how does the solution meets the requirement ? >> For example, if a control description has part a, B, C, the CSP needs to ensure that it addresses the who, what, where, when, how. >> A good rule of thumb is to provide more information than less. Responses need to be unambiguous, specific, complete, and comprehensive. You need to include the names of components, all components that make up a solution and clearly defined vendor and customer responsibilities >> Rarely will a one sentence response or a regurgitation of the requirements be enough >> You may reference other sections of the SSP supporting documentation or external guidance in your responses. The most important part of using references is to ensure that the reference is relevant. The response containing and non-relevant reference to the control will not be considered satisfactory and will be returned for revision. We would like you to follow these simple steps >> When citing a reference, the boat points to another section, make sure to include the section number of the referenced in the SSP . The role of the system admin has privileges divined defined in section 9.3 >> When citing external documents, NIST , please include the full title, publication date and the version number for the reference. Also included. Asked the nation of why the reference is cited in the response >> We talked about putting together a control respond. Let's take a look at a poor example >> This is an example of a bad response. Security settings of information technology products used within the Extech system I said to the most restrictive mode consistent with the information system operational requirements. From NIST special publication 800 70, guidance was received unnecessary configuration settings for information technology products. This response is to shorten lacks detail and does not include information about configuration settings. Section ABC are not addressed. This just spits back the requirements it does not address the actual requirements. The reference is wrong. 800 70 talks about using checklists, but is not a checklist for configuration settings. It does not address control enhancements one and three >> Now let's look at a better example of how to describe control CM six >> All servers, databases, and workstations are configured according to the Center for Internet security level I guidelines. Configuration settings are implemented and updated weekly by the system administrator. No system component is exempt from compliance with a CIF level I setting >> Tmax monitors and controls changes to configuration settings by using VZV monitoring system. Any and all changes must go to the official change request process. Or information can be found in the configuration management plan appended to the document. ZDV monitoring system is able to detect unauthorized system changes. Upon detection of an unauthorized change a system >> You can see the difference in this improved response. It provides specifics that answer requirements about configuration settings such as specifically naming the components that are configured. It addresses all sections ABCD and the control summary information table. The new description properly cites the reference or external documentation. The Center for Internet security, level I guidelines. It provides responses for control enhancement one and three >> Before completing your system security plan, I encourage everybody to download and read the guide to understanding FedRAMP . It gives a good overview of FedRAMP and guidance to understand FedRAMP requirements . How to describe your system boundaries and how to respond to security controls >> We have covered the basics of developing your system security plan. We went over the basics of structure of the template and discuss how to provide structure on your system, how to combine provide control and limitation on what supporting documents you need to submit with your System Security Plan. We reviewed the stakes to avoid such as testing software and hardware inventory and providing short answers that do not provide enough detail. We provided tips on how to structure your response by covering the who, what, where, when, how and making sure the details of your document are consistent. Don't forget to review the guide to understanding FedRAMP >> We would now like to open this up for questions. Please use the chat dialogue box within the GoToMeeting. Please restrict your questions to topics addressed in this webinar. You can also submit your questions later. Your questions will be anonymous >> Is the level of data protection determined by the three PAO ? >> Label of data protection is determined by the CSP and verified by the three PAO >> How should all the documentation be submitted to FedRAMP to maintain confidentiality ? FedRAMP has a secure repository called OMB Max and it has the proper level of security to maintain security. When vendors begin working with FedRAMP it will be provided to this repository and all control to that repository is controlled by the FedRAMP PMO >> When talking about a hybrid control between the CSP and the agency, how is the portion of the control monitored, tracked and verify ? The responsibility belong to the agency specifically for their own internal responsibility. The CSP is not required to monitor how that force and of the control is being implemented by the agency >> Is that completed SSP that we can review ? For confidentiality reasons, we would not reveal a SSP submitted to us by a provider to anybody else. I think that is the reason that the template is so detailed so that it will allow completeness of the information we need without having to look at any samples >> Is there a FedRAMP form available ? >> Is there some sort of special interest group around FedRAMP , the answer is no, not yet, but for confidentiality reasons we have not revealed who all the applicants are to the program. There is a special interest group that the third-party assessors have formed, but we would be interested in such a thing, but right now we are focusing on getting our applicants educated and granting an ATO to CSP >> Should the dataflow only focus on boundary related events would you want internal data information as well ? You need to focus on both internal and boundary related information >> Does the three PO have any role in the process or is the three PO engage to review the SSP ? >> The only do the testing, they cannot be engaged to create the SSP >> That is a very important point. The three PAO must retain their independence and must be able to review documentation without participating in the creation of those documents >> You can hire a three PAO to create your SSP or to assist you. Many CSP's have found that to be very helpful. But the three PAO cannot be the same that tests >> In the cloud implementations software components will move from physical host to physical host, how is this described in section 89 of the SSP ? This is where you describe how your live migration strategy works and in the guide to understanding FedRAMP there is a section that will help you figure out how to describe your live migration strategy and what other kinds of things that we are looking for in that description >> Can you confirm that all cloud services, even those provided by government agencies are subject to FedRAMP ? All cloud services whether commercial or government or platform software infrastructure are all subject to FedRAMP >> This is documented in a memo that was released by OMB on December 8 of 2011. That memo are available on tran1.gov >> Does it still follow the high watermark for low high and water moderate classification ? WriteNow FedRAMP is not processing any high sensitivity systems. That is not something that we should ever see that has been sent in right now >> And agencies use a cloud provider that has not gone through the jab for approval ? For more details on cloud service providers with varying levels of authorization, you can review the first webinar that we had >> At my agency they want to define everything as a cloud. Is there a good way to validate that the system is a cloud before going through the FedRAMP process ? One thing that you can always refer to is the NIST cloud reference architecture. Generally speaking cloud systems have the ability to expand rapidly on-demand. Think of it as buying your services like an accordion and when you need them, your resources expand out, you get more memory and space and when you do not need them, it contracts. Another thing that is typically common to a cloud is that live migrations are occurring behind the scenes, meaning data can move around from place to place, different storage places, different hose, undergoes to you, unbeknownst to you is still available to you. >> You should check out the NIST cloud computing architecture for framework within you can determine if your system is a cloud or not >> How do third-party audits [Indescernible-static] integrity and availability ? >> FedRAMP requires that you must have requirements and you can leverage documentation in terms of creating your SSP, but when it comes to testing, you must have it in accordance with the requirements of the test plan provided within the security assessment plan >> Parameters are entered within the control description, however, it is also listed in a separate field location on the template. Can we just write the parameters listed above that are already written as they are predefined by the JB, it seems redundant to Andrew Trice enter it twice >> The idea is not to just copy and paste, you have to check and make sure that your system can meet these parameters. If it does not, you should say what are the parameters that it does me. Meet when the third-party assessor is going in, they are going to be checking if you really need these parameters or did you just copy and paste them from below because without checking, you're not going to know if you actually meet these parameters >> If we have not gotten to your question, they will be sent out within a week or so to everybody who registered and attended the webinar. The slides will also be available on tran1.gov shortly so you can go through the detailed parts of the slide if you missed anything during our presentation >> Thank you for your time today and we look forward to seeing you on our next open our >> Webinar >> [event concluded]