@ -60,11 +60,12 @@ These systems include:
Webserver + database (core server(s))
< / li > < li >
Signing service (signing server)
< / li > < li >
Support interface
< / li > < li >
Source code (changes and patches)
< / li > < / ol >
< p >
Board may add additional components into the Security Manual.
< / p >
< h4 > < a name = "1.1.1" > 1.1.1.< / a > Effected Personnel < / h4 >
@ -361,7 +362,7 @@ All physical accesses are logged and reported to all.
< h4 > < a name = "2.3.4" > 2.3.4.< / a > Emergency Access < / h4 >
< p >
There is no procedure for emergency access.
There must not be a procedure for emergency access.
< span class = "change" >
If, in the judgement of the systems administrator,
emergency access is required and gained,
@ -369,7 +370,7 @@ in order to avoid a greater harm,
independent authorisation before the
Arbitrator must be sought as soon as possible.
< / span >
See DP R.
See DRP .
< / p >
< h4 > < a name = "2.3.5" > 2.3.5.< / a > Physical Security codes & devices < / h4 >
@ -409,7 +410,10 @@ systems and servers which do not require access
to the Internet for their normal operation
must not be granted that access.
< span class = "change" >
Any exceptions must be documented in the Security Manual.
If such access becomes temporarily necessary for an
authorized administrative task,
such access may be granted under the procedures of the SM
and must be reported and logged.
< / span >
< / p >
@ -431,7 +435,7 @@ All ports on which incoming traffic is expected shall be documented; traffic to
< h5 > 3.1.2.2. Egress < / h5 >
< p >
All ports to which outbound traffic is initiated shall be documented; traffic to other port s must be blocked. Unexpected traffic must be logged as an exception.
All outbound traffic that is initiated shall be documented; traffic to other destination s must be blocked. Unexpected traffic must be logged as an exception.
< / p >
< h4 > < a name = "3.1.3" > 3.1.3.< / a > Intrusion detection < / h4 >
@ -533,7 +537,7 @@ controlled and logged.
< span class = "change" >
General access for Members shall be provided via
a dedicated web application.
a dedicated application.
General features are made available according to
Assurance Points and similar methods controlled in
the software system.
@ -562,13 +566,13 @@ authorisations on the below access control lists
< td > Access Engineers< / td >
< td > control of access by personnel to hardware< / td >
< td > exclusive of all other roles < / td >
< td > Boards of CAcert (or designee)< / td >
< td > Board of CAcert (or designee)< / td >
< / tr > < tr >
< td > Physical Access List< / td >
< td > systems administrators< / td >
< td > hardware-level for installation and recovery< / td >
< td > exclusive with Access Engineers and Software Assessors< / td >
< td > Boards of CAcert (or designee)< / td >
< td > Board of CAcert (or designee)< / td >
< / tr > < tr >
< td > SSH Access List< / td >
< td > systems administrators< / td >
@ -598,7 +602,8 @@ All changes to the above lists are approved by the board of CAcert.
< p >
< span class = "change" >
Strong methods of authentication shall be used.
Strong methods of authentication shall be used
wherever possible.
All authentication schemes must be documented.
< / span >
< / p >
@ -679,7 +684,8 @@ and reported in regular summaries to the board of CAcert.
< p >
All sensitive events should be logged.
Logs should be deleted after an appropriate amount of time.
Logs should be deleted after an appropriate amount of time
as documented in the Security Manual.
< / p >
< h4 > < a name = "4.2.2" > 4.2.2.< / a > Access and Security < / h4 >
@ -786,7 +792,6 @@ See §4.2.1.
< h4 > < a name = "4.4.3" > 4.4.3.< / a > Incident reports < / h4 >
< p >
Document.
See § 5.6.
< / p >
@ -797,10 +802,6 @@ See §5.6.
< h3 > < a name = "5.1" > 5.1.< / a > Incidents < / h3 >
< p >
Incidents and sources of important events and logging should be documented.
< / p >
< h3 > < a name = "5.2" > 5.2.< / a > Detection < / h3 >
< p >
The standard of monitoring, alerting and reporting must be documented.
@ -845,7 +846,8 @@ Management starts with the team leader and ends with the Board.
< p >
Incidents must be investigated.
The investigation must be documented.
Evidence must be secured if the severity is high.
If the severity is high,
evidence must be secured and escalated to Arbitration.
< / p >
< h3 > < a name = "5.5" > 5.5.< / a > Response < / h3 >
@ -1053,8 +1055,33 @@ policies and practices.
< h3 > < a name = "8.2" > 8.2. < / a > Responsibilities < / h3 >
< span class = "change" >
< p >
Support Engineers have these responsibilities:
< p >
< ul > < li >
Account Recovery, as documented in the Security Manual.
< / li > < li >
Respond to general requests for information or explanation by Members.
Support Engineers cannot make a binding statement.
Responses must be based on policies and practices.
< / li > < li >
Tasks and responsibilities as specified in other policies, such as DRP.
< / li > < / ul >
< / span >
< h3 > < a name = "8.3" > 8.3. < / a > Channels < / h3 >
< p >
< span class = "change" >
Support may always be contacted by email at
support at cacert dot org.
Other channels may be made available and documented
in Security Manual.
< / span >
< / p >
< h3 > < a name = "8.4" > 8.4. < / a > Records and Logs < / h3 >
< ul >
@ -1255,9 +1282,9 @@ to coordinate technical testing and training,
especially of new team members.
< / p >
< h3> < a name = "9.2" > 9.2. < / a > Key changeover< / h3 >
< p class = "q" > what goes in here? Non-root keys? Strike this section? Or merge it as Root Keys with 9.3, 9.4....< / >
< span class = "change" >
< h3 > < a name = "9.2" > 9.2. < / a > < s > Key changeover < / s > < / h3 >
< / s pan >
< h3 > < a name = "9.3" > 9.3. < / a > Key generation/transfer< / h3 >
@ -1285,11 +1312,16 @@ Subroots may be escrowed by either Board or Systems Administration Team.
< h4 > < a name = "9.3.3" > 9.3.3. < / a > Recovery< / h4 >
< p >
Recovery must only be conducted under Board or Arbitrator direction.
Recovery must only be conducted
< span class = "change" >
under Arbitrator authority.
< s >
A recovery exercise should be conducted approximately every year.
< / s >
< / span >
< / p >
< h3 > < a name = "9.4" > 9.4. < / a > Root certificate changes< / h3 >
< h3 > < a name = "9.4" > 9.4. < / a > < span class = "change" > < s > < / s > < / span > < / h3 >
< h4 > < a name = "9.4.1" > 9.4.1. < / a > Creation< / h4 >
Ian Grigg
16 years ago