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. [ ] b. List those requirements met by the project. [ ] c. Are there any specific security requirements which your project does not plan to meet? [ ] [X] No a. What security issues are being addressed or potentially introduced by your project. [ NetBeans Ruby support launches 3rd party products such as servers, which themselves may expose security risks, in case they have a security issue. This is typically not a problem, as the user can update a potential insecure version of the server to a new one which addresses the security issue through the NetBeans user interface. Next, developer machines are typically not visible from the internet (e.g. hidden behind a firewall), so the potential security risk is not exposed to attackers. ] 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. [ This consolidation does not contain any services. ] 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. [ dtto ] c. How are the other aspects of the policy met ( e.g., warning to the administration about install options which are non-compliant) [ This consolidation does not control the installation process, so this does not apply. The installation should be reviewed as an aspect of the Platform ARC case WSARC 2007/344 ] 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) [ The Ruby support does uses network connections for installing the Ruby gem files. The IDE does not establish these connections directly - rather, it delegates to external tools from the Ruby platform, so it merely acts as a UI wrapper for these command line tools. ] 3. Describe how to disable each service from your project and the side effects (e.g. dependencies) of doing so. [ Not applicable, the project does not contain services. ] 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? [?] Yes 1. Describe how your project authenticates or discover the host, user, or services identity? [ N/A ] 2. If authentication is done by another component explain how you obtain this information and why you believe its authentic. [ N/A ] 3. If your project authenticates, explain the authentication process including any standards or existing components used. [ N/A ] 4. In addition, describe what happens if the authentication process fails. [ N/A ] 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. [ N/A ] [?] No b. Does your project make decisions about whether a requestor may access a particular resource? [?] Yes Explain how this occurs for both successful and unsuccessful access requests. [ N/A ] [?] No c. Does your project protect its communications from passive listeners on the network? [?] Yes Explain the techniques used to accomplish this. [ N/A ] [?] No Explain why not. [ N/A ] 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). [ N/A ] e. Does your service protect the integrity of its communications over the network? [?] Yes Explain the techniques used to accomplish this. [ N/A ] [?] No Explain why not. [ N/A ] f. Describe how network communication is protected against replay attacks in which a partial record of an earlier network exchange is replayed [ N/A ] 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) [ N/A ] 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 [ TCP/IP ] b. describe what information will flow and/or be made available over this network connection [ This information is determined by the external tools that NetBeans uses, e.g. to manage Ruby gem files.] 6. Does this project use secret information (e.g. passwords, passphrases, PINs or equivalent authenticators) during authentication and/or authorization? [X] Yes a. Describe all methods for how this secret information can be obtained (e.g. user prompted interactively.) [ The IDE relies on the authorization and authentication mechanisms (namely, file access permissions) provided by the underlying operating system. It does not manipulate passwords directly.] 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 [ Not applicable ] 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 [ Not applicable ] b. Describe how the secret information is: created, provisioned, updated, revoked, and checked for policies regarding its content (e.g. password strength checks.) [ Not applicable, NetBeans only acts as a client that uses other software's passwords. ] c. How is this secret information expunged from the project's memory after use (e.g. so it doesn't appear in core files?) [ As NetBeans launches external tools that may manipulate this information, it is expunged when the external tool completes its execution. ] [_?_] 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). [ This consolidation does not control the installation process, so this does not apply. The installation should be reviewed as an aspect of the Platform ARC case WSARC 2007/344 ] 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. [ Not applicable ] [X] No a. Describe how/where authentication and authorization checks are done. [ Using the underlying operating system, when launching external tools ] b. List the roles, rights, and authorizations needed to access the functionality included in this project. [ To install new gems, the user must have the right to execute the external gem tool, and the right to write to the directories controlled by the tool. ] 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. [ It delegates, see above. ] 9. Except for networking (discussed above), does this project use cryptography for any purpose? [ ] Yes a. For each use of cryptography in this project, describe the algorithms, key sizes and design for how it is being used. If any non-standard cryptographic algorithms or protocols are used, describe why that algorithm and protocol was selected. [ Not applicable ] b. For each use of cryptographic keys or certificates specify: 1. what types of keys and/or certificates are used, [ Not applicable ] 2. what they are used for, [ Not applicable ] 3. how they are created, updated, and deleted, [ Not applicable ] 4. where they are stored, and [ Not applicable ] 5. what the secure backup and recovery method is. [ Not applicable ] c. Export classification: 1. What crypto export classification will the project and product have? [ Not applicable ] 2. For projects and products with a non-retail crypto export classification, what design features are incorporated to allow for the substitution of a cipher which has retail approval. [ Not applicable ] [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. [ Not applicable ] b. In addition, list all privileges required for this software. [ Not applicable ] [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 [ ] Yes a. List all security error events that may be generated and their causes. [ None ] b. Will this project generate any audit records? [ ] Yes List those events for which you will generate audit records. [ None ] [ ] No Describe why not. [ N/A ] [X] No 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)? [ ] Yes a. Against which standards will it be evaluated? [ ] Common Criteria: which protection profiles (e.g., CAPP) and to what assurance level (e.g., EAL4) [ N/A ] [ ] FIPS 140-2: what level (1 to 4) is the evaluation? [ N/A ] [ ] Other: Provide specific details [ N/A ] b. What already-evaluated mechanisms (e.g., auditing) will your project be using to make this possible and as simple as possible? [ N/A ] c. What already-evaluated mechanisms was your project not able to leverage and why? [ N/A ] [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) [ Data corrruption does not represent a security vulnerability for NetBeans ]