diff --git a/SecurityPolicy.html b/SecurityPolicy.html index 75534ca..119e6e1 100644 --- a/SecurityPolicy.html +++ b/SecurityPolicy.html @@ -77,7 +77,7 @@ These roles are directly covered:
  • Systems Administrators
  • - Supporters + Support Engineer
  • Software Assessors
    • @@ -114,6 +114,8 @@ Important principles of this Security Policy are: two people from different areas
  • Audit -- where external reviewers do checks on practices and policies +
  • + Authority -- every action is authorised by either a policy or by the Arbitrator.

    • @@ -131,14 +133,14 @@ deriving from the above principles. See §1.1. -

    Software Assessor
    +
    Software Assessor
    A Member who reviews patches for security and workability, signs-off on them, and incorporates them into the repository. See §7.
    -
    Support ??? noun needed here
    +
    Support Engineer
    A Member who mans the support list, and has access to restricted @@ -148,7 +150,7 @@ deriving from the above principles.
    Systems Administrator
    - A Member who manages a critial system, and has access + A Member who manages a critical system, and has access to security-sensitive functions or data.
    @@ -167,6 +169,11 @@ It is under the control of Policy on Policy for version purposes.

    This policy document says what is done, rather than how to do it. + + +Some sections are empty, which means +"refer to the Manual." +

    1.4.2. The Security Manual (Practices) Document

    @@ -186,6 +193,10 @@ It is located and version-controlled on the CAcert wiki. Section Headings are the same in both documents. Where Sections are empty in one document, they are expected to be documented in the other. + +"Document further in Security Manual" can be implied from +any section heading in the Policy. +

    1.4.3. The Security Procedures

    @@ -232,7 +243,9 @@ List must be subject to change control.

    -Units shall have nickname clearly marked on front and rear of chassis. + +Each unit shall be distinctly and uniquely identified on all visible sides. + Machines shall be housed in secured facilities (cages and/or locked racks).

    @@ -247,8 +260,6 @@ prepared in advance.

    2.2.2. Service

    -

    Wytze: new section replacing 'cables':

    -

    Equipment that is subject to a service security risk must be retired if service is required. @@ -331,8 +342,12 @@ one systems administrator present.

    -Only Systems Administrators are authorised to access the data. -All others must not access the data. + +There is no inherent authorisation to access the data. +Systems Administrators are authorised to access +the raw data under the control of this policy. + +All others must not access the raw data. All are responsible for protecting the data from access by those not authorised.

    @@ -347,9 +362,14 @@ All physical accesses are logged and reported to all.

    There is no procedure for emergency access. -If emergency access is gained, -this must be reported and justified immediately. -See DPR. + +If, in the judgement of the systems administrator, +emergency access is required and gained, +in order to avoid a greater harm, +independent authorisation before the +Arbitrator must be sought as soon as possible. + +See DPR.

    2.3.5. Physical Security codes & devices

    @@ -366,13 +386,31 @@ codes and devices (keys) are to be authorised and documented.

    3.1.1. Infrastructure

    -Current and complete diagrams of the physical and logical CAcert network infrastructure shall be maintained by systems administration team leader. These diagrams should include cabling information, physical port configuration details, and expected/allowed data flow directions, as applicable. Diagrams should be revision controlled, and must be updated when any change is made. +Current and complete diagrams of the physical and logical +CAcert network infrastructure shall be maintained by +systems administration team leader. +These diagrams should include cabling information, +physical port configuration details, +expected/allowed data flow directions, + +and any further pertinent information, + +as applicable. +Diagrams should be revision controlled, +and must be updated when any change is made.

    3.1.1.1. External connectivity

    -Only such services as are required for normal operation should be visible externally; systems and servers which do not require access to the Internet for their normal operation must not be granted that access. +Only such services as are required for normal operation +should be visible externally; +systems and servers which do not require access +to the Internet for their normal operation +must not be granted that access. + +Any exceptions must be documented in the Security Manual. +

    3.1.1.2. Internal connectivity
    @@ -445,47 +483,73 @@ an emergent local exploit may also be deemed to be an emergency). Application of patches in this case may occur as soon as possible, bypassing the normal configuration-change process. The systems administration team leader must either approve the patch, -instruct remedial action, or refer the case to dispute resolution. +instruct remedial action, + +and + +refer the case to dispute resolution.

    Declaration of an emergency patching situation should not occur with any regularity. -Emergency patch events must be documented within the regular summaries to Board. +Emergency patch events must be documented +within the regular summaries + +by the team leader to Board +independent of filed disputes. +

    3.3. Application

    -Software assessment takes place on various test systems (not a critical system). See §7. Once offered by Software Assessment (team), system administration team leader has to approve the installation of each release or patch. +Software assessment takes place on various test systems +(not a critical system). See §7. +Once offered by Software Assessment (team), +system administration team leader has to +approve the installation of each release or patch.

    -Any changes made to source code must be referred back to software assessment team. +Any changes made to source code must be referred +back to software assessment team + +and installation needs to be deferred +until approved by the Software Assessment Team. +

    3.4. Access control

    -

    - These two paras seem in wrong place. - Either add a "3.4.3. User Access" or? -

    -

    -General user access to CAcert services shall normally be conducted through a web-based application interface. Features are made available according to Assurance Points and direct permissions. + +All access to critical data and services shall be +controlled and logged. + + +

    3.4.1. Application Access

    + + +General access for Members shall be provided via +a dedicated web application. +General features are made available according to +Assurance Points and similar methods controlled in +the software system. +

    -

    -Direct Permissions are managed by the Application to enable special online administrators from the Support Team access to certain functions. -

    +

    what about web-api interfaces? Excluded?

    -

    3.4.1. Authorisation

    - -

    This bit is expanded!

    +

    3.4.2. Special Authorisation

    -The access control lists (see §1.1.1) are: + +Additional or special access is granted according to the +authorisations on the below access control lists + +(see §1.1.1):

    @@ -499,13 +563,13 @@ The access control lists (see §1.1.1) are: - + - + @@ -514,8 +578,8 @@ The access control lists (see §1.1.1) are: - - + + @@ -531,13 +595,16 @@ The access control lists (see §1.1.1) are: All changes to the above lists are approved by the board of CAcert.

    -

    3.4.2. Authentication

    +

    3.4.3. Authentication

    -A strong method of authentication is used and documented. + +Strong methods of authentication shall be used. +All authentication schemes must be documented. +

    -

    3.4.3. Removing access

    +

    3.4.4. Removing access

    Follow-up actions to termination must be documented. @@ -574,8 +641,11 @@ to CAcert sysadmins in all cases.

    Only system administrators designated on the Access Lists -in §3.4.1 -shall be authorized to access accounts. +in §3.4.2 +are authorized to access accounts, + +unless specifically directed by the Arbitrator. +

    4.1.1.2. Access to Systems
    @@ -586,17 +656,7 @@ All access is secured, logged and monitored.
    4.1.1.3. Changing

    -The procedure for changing passphrases and SSH keys should be documented. -

    - -
    4.1.1.4. Outsourcing
    - -

    -Systems administration team leader may outsource non-critical -components such as DNS servers. -Outsourcing should be to Members who are Assurers, -who have the appropriate technical knowledge, -and are in good contact with team leader. +The procedure for changing passphrases and SSH keys shall be documented.

    4.1.2. Required staff response time

    @@ -606,9 +666,14 @@ Response times should be documented for Disaster Recovery planning. See §6

    4.1.3. Change management procedures

    -All changes made to system configuration must be recorded. +All changes made to system configuration must be recorded + +and reported in regular summaries to the board of CAcert. +

    +

    4.1.4. Outsourcing

    +

    4.2. Logging

    4.2.1. Coverage

    @@ -670,6 +735,11 @@ Disaster recovery backups may be distributed.

    4.3.4. Retention period and Re-use

    +

    + +See §2.2.3. + +

    4.3.5. Encryption

    Backups must be encrypted and must only be transmitted via secured channels. @@ -709,6 +779,11 @@ See CCA.

    4.4.2. System logs

    +

    + +See §4.2.1. + +

    4.4.3. Incident reports

    @@ -741,8 +816,14 @@ an initial assessment of severity and priority must be made.

    5.2.2. Communications

    -An initial report should be sent to systems administrators +An initial report should be + +circulated. + +sent to systems administrators and wider interested parties. + +

    @@ -750,9 +831,15 @@ A communications forum should be established for direct support of high priority or high severity incidents.

    -

    5.2.3. Oversight

    +

    5.2.3. Escalation

    -A process of escalation of oversight should be eastablished. +A process of escalation should be established + +for oversight and management purposes, +proportional to severity and priority. +Oversight starts with four eyes and ends with the Arbitrator. +Management starts with the team leader and ends with the Board. +

    5.4. Investigation

    @@ -767,7 +854,7 @@ Evidence must be secured if the severity is high.

    5.6. Report

    -Incident reports must be published. +Incident reports shall be be published. The Incident Report is written on closing the investigation. A full copy should be appended to the documentation of the investigation. @@ -778,22 +865,14 @@ for publication and maintenance.

    -Incidents are not normally kept secret nor confidential. +Incidents are not normally kept secret nor confidential, and progress information should be published as soon as possible. The knowledge of the existence of the event must not be kept secret, nor the manner and methods be kept confidential. -

    - -

    -The following is a general confidentiality and secrecy -clause. Suggest moving this to new section 9.7. -

    - -

    -Only under a defined exception under policy, -or under the oversight of the Arbitrator, -may confidentiality be maintained. + +See §9.7. +

    6. DISASTER RECOVERY

    @@ -826,6 +905,10 @@ Board must have a basic plan to recover. Board must maintain a key persons List with all the contact information needed. See §10.1. + +The list shall be accessible even if CAcert's +infrastructure is not available. +

    @@ -846,7 +929,7 @@ for the security of the code.

    The source code is under CCS. Additions to the team are approved by Board. -See §3.4.1. +See §3.4.2.

    7.2. Tasks

    @@ -943,19 +1026,21 @@ See §3.3.

    8.1. Authority

    -The software interface gives features to Support personnel. +The software interface gives features to Support Engineer. Access to the special features is under tight control. Additions to the team are approved by Board, and the software features are under CCS. + +See §3.4.2. +

    -Support personnel do not have any inherent authority +Support Engineers do not have any inherent authority to take any action, -and they have have to get authority on a case-by-case -basis. +and they have have to get authority on a case-by-case basis. The authority required in each case must be guided -by this policy or the Security Manual or other clear +by this policy or the Security Manual or other clearly applicable document. If the Member's authority is not in doubt, the Member can give that authority. @@ -963,7 +1048,7 @@ If not, the Arbitrator's authority must be sought.

    -Support personnel are responsible to follow the +Support Engineers are responsible to follow the policies and practices.

    @@ -971,23 +1056,26 @@ policies and practices.

    8.3. Channels

    -

    8.4. Interface

    -

    -Access to Member's private information is restricted. -Support staff may be authorised by the Board -to access any additional, restricted interfaces. -This access is managed by the systems administration -team leader, see §3.4.1. -

    +

    8.4. Records and Logs

    -

    8.5. Records and Logs

    -

    8.6. Arbitration

    +

    8.5. Arbitration

    + +Support Engineers refer questions requiring authority +to Arbitration, and may also be called upon to act as +default Case Managers. +See DRP and +Case Manager's Handbook. +Support Engineers should be familiar with +these topics, even if not listed as Arbitrators +or Case Managers. + +

    8.6. References

    @@ -1001,7 +1089,7 @@ team leader, see §3.4.1.
  • Access Engineer: responsible for controlling access to hardware, and maintaining hardware.
  • System administrator: responsible for maintaining core services and integrity.
  • Software assessor: maintain the code base and confirm security ("sign-off") of patches and releases.
    • -
  • Support: human interface with users.
    • +
  • Support Engineer: human interface with users.
  • Team leaders: coordinate with teams, report to board.
  • All: respond to Arbitrator's rulings on changes. Respond to critical security issues. Observe.
  • Board: authorise new individuals and accesses. Coordinate overall.
    • @@ -1014,7 +1102,7 @@ Each team should have a minimum of two members available at any time. Individuals should not be active in more than one team at any one time, but are expected to observe the other teams. -See §3.4.1 for exclusivities. +See §3.4.2 for exclusivities.

    @@ -1069,7 +1157,7 @@ The background check should be done on all of:

  • systems administrator
  • access engineeers
  • software assessor
    • -
  • support
    • +
  • support engineer
  • Board
    • @@ -1148,7 +1236,7 @@ and may be reversed. Termination of access may be for resignation, Arbitration ruling, or decision of Board or team leader. On termination (for any reason), access and information must be secured. -See §3.4.3. +See §3.4.4.

    @@ -1170,7 +1258,7 @@ especially of new team members.

    9.2. Key changeover

    -

    what goes in here? Non-root keys?

    +

    what goes in here? Non-root keys? Strike this section? Or merge it as Root Keys with 9.3, 9.4....

    9.3. Key generation/transfer

    @@ -1243,10 +1331,11 @@ and becomes your authority to act.

    9.6. Outsourcing

    -

    -CAcert may at its option outsource critical components to -other organisations, however this must not be a barrier -to security. Outsourced arrangements must be transparent. +

    +Components may be outsourced. +Team leaders may outsource non-critical components +on notifying the board. +Critical components must be approved by the board.

    @@ -1254,26 +1343,55 @@ Any outsourcing arrangements must be documented. All arrangements must be:

    -
    Access Engineers control of access by personnel to hardware exclusive of all other roles Boards of CAcert and of OophagaBoards of CAcert (or designee)
    Physical Access List systems administrators hardware-level for installation and recovery exclusive with Access Engineers and Software AssessorsBoards of CAcert and of OophagaBoards of CAcert (or designee)
    SSH Access List systems administratorssystems administration team leader
    Support Access Listsupporterssupport features in the online interfaceSupport Engineersupport features in the web application includes by default all systems administrators systems administration team leader