Updated: 03/22/07 sac>Best Practices>ARC Security Questions Systems Architecture ARC Security Questions Council Overview Policy Synopsis Category Software Owner Security-SWG Sponsor SAC The Security SWG wants to extend the scope, detail, and depth of Author Security-SWG security-related information reviewed by the ARC's during a Changes sec-swg@Sun.Com project's inception and commitment reviews. By gathering this Authority SAC additional information the ARCs will be better able to determine Policy Version 2.1 the security implications of the project under review. Approved Status 2003/08/12 (v1), The Security SWG recommends that a reference to this policy be 2006/12/20 (v2) included within each ARC's 20 questions, replacing any security Last Reviewed updated 2006/12/20 questions that may currently exist. All projects starting Effective the ARC review process See after 2007/01/15 http://sac/BestPractices/Security.txt for a text version of this policy. Obsoletes ARC Security Questions v1.x ---------------------------------------------------------------------------- Applicability All projects ---------------------------------------------------------------------------- Audience Project leads, ARCs, PACs ---------------------------------------------------------------------------- Policy * Applies to All projects * Authority SAC * Effective All projects starting the ARC review process after 2007/01/15 * Obsoletes ARC Security Questions v1.x * Policy Project Case Materials must include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. Projects must highlight information for the following important areas: * What features are newly visible on the network and how are they protected from exploitation (e.g. unauthorized access, eavesdropping) * If the project makes decisions about which users, hosts, services, ... are allowed to access resources it manages, how is the requestor's identity determined and what data is used to determine if the access granted. Also how this data is protected from tampering. * If this project uses any privileged operations beyond what a common user (e.g. "noaccess") can perform, why those are necessary and how they are granted. * What parts of the project are active upon default install and how they can be turned off. * Details This Security Questionnaire is designed to collect detailed information regarding the security implications of additions and changes to SMI's product lines. When answering all of the following questions please describe when an environmental security assumption is the basis for an "Not Applicable" answer. 1. Are there any security requirements documented for this project? [?] Yes a. Describe what version of the requirements document was used and where it can be found. [ answer ] b. List those requirements met by the project. [ answer ] c. Are there any specific security requirements which your project does not plan to meet? [ answer ] [X] No a. What security issues are being addressed or potentially introduced by your project. See the following sections of the SAM-QFS Functional Specification: 8.1 Areas of Responsibility 2. For each service that is created, installed, used, or depended upon, describe, how it is compliant with the Install-Time Security Policy ( http://sac/cgi-bin/bp.cgi?NAME=ITS.bp and/or http://www.opensolaris.org/os/community/arc/policies/ITS/ a. Specifically, how does each outbound service meet the protection requirements using: SVC1, SVC2, or SVC[3,4]) including how OUT[1-3] protection is enforced. See the following sections of the SAM-QFS Functional Specification: 8.5.2 Service Guidance b. Specifically, how does each inbound service meet the protection requirements using: SVC1, SVC2, or SVC[3,4] including how IN[1,2] protection is enforced. See the following sections of the SAM-QFS Functional Specification: 8.5.2 Service Guidance c. How are the other aspects of the policy met ( e.g., warning to the administration about install options which are non-compliant) See the following sections of the SAM-QFS Functional Specification: 8.5.1 Administrator Input d. Also, list the service/application to which this project will communicate and the mechanism used (if external network interfaces are used, or the connection uses purely local interconnects, and if IP based list static/dynamic ports used) See the following sections of the SAM-QFS Functional Specification: 8.5.2 Service Guidance 3. Describe how to disable each service from your project and the side effects (e.g. dependencies) of doing so. See the following sections of the SAM-QFS Functional Specification: 3.8 Un-Install 4. For each service, discuss how it protects its communications from: theft, replay, content change and user impersonation within the following sub-sections: a. Does your service make decisions based on user, host or service identities? [X] Yes 1. Describe how your project authenticates or discover the host, user, or services identity? See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources 2. If authentication is done by another component explain how you obtain this information and why you believe its authentic. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources 3. If your project authenticates, explain the authentication process including any standards or existing components used. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources 4. In addition, describe what happens if the authentication process fails. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources 5. If passwords or passphrases are used, discuss how they are protected from host or network-based theft, protected if stored beyond authentication, how they can be changed, and any validity checking which occurs. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources [?] No b. Does your project make decisions about whether a requestor may access a particular resource? [X] Yes Explain how this occurs for both successful and unsuccessful access requests. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources [?] No c. Does your project protect its communications from passive listeners on the network? [X] Yes Explain the techniques used to accomplish this. See the following sections of the SAM-QFS Functional Specification: 8.3.5 Filesystem Network Security Policy Statement [?] No Explain why not. d. Describe how host and network-based access control are provided (e.g., this could be provided through technologies such as host-based firewalls/IPsec or application-level controls such as TCP Wrappers). See the following sections of the SAM-QFS Functional Specification: 8.3.5 Filesystem Network Security Policy Statement 8.4 Access to SAM-QFS Resources e. Does your service protect the integrity of its communications over the network? [X] Yes Explain the techniques used to accomplish this. See the following sections of the SAM-QFS Functional Specification: 8.3.5 Filesystem Network Security Policy Statement 8.4 Access to SAM-QFS Resources [?] No Explain why not. f. Describe how network communication is protected against replay attacks in which a partial record of an earlier network exchange is replayed See the following sections of the SAM-QFS Functional Specification: 8.3.5 Filesystem Network Security Policy Statement g. Describe how your network communications could be exploited by a denial of service (DoS) attack. (For instance, what resources are allocated during session setup before the requestor has been authenticated) See the following sections of the SAM-QFS Functional Specification: 8.3.5 Filesystem Network Security Policy Statement 5. For each network (e.g., RPC over IP, TCP/IP, Serial, etc.) used by a project describe the following: a. describe the protocol stack being used See the SAM-QFS Protocol Specification document. b. describe what information will flow and/or be made available over this network connection See the SAM-QFS Protocol Specification document. 6. Does this project use secret information (e.g. passwords, passphrases, PINs or equivalent authenticators) during authentication and/or authorization? [_?_] Yes a. Describe all methods for how this secret information can be obtained (e.g. user prompted interactively.) 1. If the secret information can be obtained via command line or environment variable, explain how the project complies with the SAC Reusable Passwords policy at: http://sac.eng/swg/Security/recommendations/reusable_password_policy_v1.0.txt 2. If the secret information can be obtained from persistent storage (e.g. file), explain how the storage is protected and compliant with the SAC Storing Reusable Passwords policy at: http://sac.eng/swg/Security/recommendations/SecSWG_Policy_ReusablePW_FS_v1.0.txt b. Describe how the secret information is: created, provisioned, updated, revoked, and checked for policies regarding its content (e.g. password strength checks.) c. How is this secret information expunged from the project's memory after use (e.g. so it doesn't appear in core files?) [_X_] No 7. Describe how the project uses the file system in a way that is compliant with the FILE SYSTEM GUIDANCE section of the Install-Time Security Policy (see above) for cases other than storage of secret information (previous question). See the following sections of the SAM-QFS Functional Specification: 8.5.3 Filesystem Guidance 8. Does a non-privileged (e.g., not having access equivalent to uid 0 on pre-RBAC/Least Privilege OEs) user have access to all project functionality? [_?_] Yes a. Describe why there are no potential RASS (Reliability, Availability, Serviceability, and Security) reasons to restrict non-privileged access. [ answer ] [_X_] No a. Describe how/where authentication and authorization checks are done. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources b. List the roles, rights, and authorizations needed to access the functionality included in this project. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources c. Does your project perform authorization checking itself or does it use another component? If itself, explain how this occurs and why this project has its own authorization system. See the following sections of the SAM-QFS Functional Specification: 8.4 Access to SAM-QFS Resources 9. Except for networking (discussed above), does this project use cryptography for any purpose? [_X_] No 10. Is any privileged user or group account (e.g., suid root, or other privileged setting mechanism) software part of your project? [_?_] Yes a. Describe how the principle of least privilege (e.g. daemon dropping privileges once no longer needed) has been applied. [ answer ] b. In addition, list all privileges required for this software. [ answer ] [_X_] No 11. Are any log, error, FMA, or audit events generated? Note - this question applies to all auditing mechanisms, whether implemented in Solaris auditing, J2SEs logging facility, or Windows event logging [_X_] Yes a. List all security error events that may be generated and their causes. See the following sections of the SAM-QFS Functional Specification: 3.4 Diagnostic Procedures and Tools b. Will this project generate any audit records? [_X_] Yes List those events for which you will generate audit records. 12. Will the project undergo a security evaluation/certification by itself or as part of a larger product (e.g. Solaris releases are certified against the Common Criteria's CAPP at EAL4)? [_X_] No 13. How does the project provide for failsafe defaults such that the security is not compromised? (For example, how does the project ensure that the security of the product isn't compromised by corrupted or missing configuration files) See the following sections of the SAM-QFS Functional Specification: 4.3.8 Configuration Corruption