DOCSLIB.ORG

Bivio 6310-NC Common Criteria Administrative Guidance

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Bivio 6310-NC Common Criteria Administrative Guidance Bivio 6310-NC Common Criteria Administrative Guidance Version 1.10 Nov 23, 2020 Bivio 6310-NC Common Criteria Administrative Guidance CONTENTS 1. Introduction .......................................................................................................................................... 5 2. Operational Environment – IT Requirements ....................................................................................... 6 3. Operational Environment – Procedural/Policy Requirements ............................................................. 7 4. Installation and Initial Configuration .................................................................................................... 7 Initial configuration ............................................................................................................................................... 8 Logging in and out of the system ........................................................................................................................ 10 Setting time ......................................................................................................................................................... 10 Enabling the NTP Client for Time Synchronization ............................................................................................. 11 Rebooting the system ......................................................................................................................................... 12 Power cycling the system .................................................................................................................................... 12 5. Configuration Items for CC Compliance .............................................................................................. 13 6. The System Administrator ................................................................................................................... 14 7. Configuring login retries and account locking..................................................................................... 14 8. Common tasks ..................................................................................................................................... 15 9. Security Audit Data Generation .......................................................................................................... 16 Storage space for audit data ............................................................................................................................... 17 Audit log rotation ................................................................................................................................................ 17 Audit storage space running low – warning ........................................................................................................ 18 Audit log entry format ........................................................................................................................................ 18 Searching audit logs ............................................................................................................................................ 20 Starting the audit daemon .................................................................................................................................. 21 Stopping the audit daemon ................................................................................................................................ 21 Admin Login / Initiation of trusted path ............................................................................................................. 22 Admin logout / User initiated termination / Termination of trusted path ......................................................... 24 Security related information ............................................................................................................................... 25 Resetting a user’s password ................................................................................................................................ 25 Starting a service ................................................................................................................................................. 25 Stopping a service ............................................................................................................................................... 26 Capture all Administrator commands ................................................................................................................. 26 Failure to establish an SSH session (client) ......................................................................................................... 27 Successful SSH rekey (client) ............................................................................................................................... 29 Failure to establish an SSH session (server) ........................................................................................................ 30 Locking of user account ...................................................................................................................................... 31 Unlocking of user account ................................................................................................................................... 31 Nov 23, 2020 Version 1.10 Page 2 Bivio 6310-NC Common Criteria Administrative Guidance Successful SSH rekey (server) .............................................................................................................................. 31 Successful authentication for a login session over TLS ....................................................................................... 32 Termination of a login session over TLS .............................................................................................................. 33 Failed authentication for a login session over TLS .............................................................................................. 33 Failure to establish a TLS session ........................................................................................................................ 34 All use of the identification and authentication mechanism .............................................................................. 35 Unsuccessful attempt to validate a certificate (TLS server) ................................................................................ 35 Software integrity checking ................................................................................................................................ 38 Modification of the behavior of the handling of audit data, and modification of the behavior of the TSF ........ 39 Trusted updates .................................................................................................................................................. 41 Changes to time .................................................................................................................................................. 41 Termination of local session by session locking mechanism .............................................................................. 42 Termination of remote session by session locking mechanism .......................................................................... 42 Initiation of trusted channel (SSH client) ............................................................................................................ 42 Termination of trusted channel (SSH client) ....................................................................................................... 44 Failure of the trusted channel (public key) ......................................................................................................... 44 Running cryptographic tests (on the OpenSSL cryptography suite) ................................................................... 45 Modification, deletion, generation/import of cryptographic keys ..................................................................... 45 Configuration of a new time server and removal of an existing time server ...................................................... 48 10. Configuring the SSH tunnel client for transporting audit logs to remote server ............................ 49 Mitigating Against CVE-2020-14145 ................................................................................................................... 52 11. Admin login authentication ............................................................................................................ 52 Password based authentication .......................................................................................................................... 53 Strong passwords ................................................................................................................................................ 53 Public key based authentication ......................................................................................................................... 54 Login session timeout ......................................................................................................................................... 55 Login warning banner ......................................................................................................................................... 55 Changing the Administrator’s password ............................................................................................................
Load more

Recommended publications
  • Treasury X.509 Certificate Policy [TREASURYCP].” It Only Addresses Where an OLT PKI’S Requirements Differ from the Requirements for Basic Assurance in [TREASURYCP]
    UNCLASSIFIED UNITED STATES DEPARTMENT OF THE TREASURY DEPARTMENT OF THE TREASURY PUBLIC KEY INFRASTRUCTURE (PKI) X.509 CERTIFICATE POLICY VERSION 3.4 April 27, 2021 PKI Policy Management Authority (PMA) DATE DANIEL W. WOOD 1 UNCLASSIFIED DOCUMENT VERSION CONTROL Version Date Author(s) Description Reason For Change Bring the Treasury PKI Policy into Department of the compliance with FPKIPA change Treasury PKI Policy in 2.0 January 2008 James Schminky proposal requiring all cross certified RFC PKI Policies to be in RFC 3647 3647 format. format. As a result of mapping the Treasury Errata changes to sections PKI Policy to Federal Policy, a 2.2.1, 2.1 March 17, 2009 James Schminky number of minor changes and 4.8, 4.912, 5.5, and omissions where identified and 7.1.3. corrected. As a result of the PMA annual Errata changes to sections review a number of minor 5.6, and 6.3.2. Change corrections, Federal Bridge proposal changes to 2.4, 2.2 March 11, 2010 James Schminky Certification Authority (FBCA) 4.2.2, 5.1, 5.1.1 5.1.2.1, Policy Change Proposal Number: 5.4.4, 5.4.5, 6.1.6, 6.5.1, 2009-02 and 2010-01, and Treasury and 6.7. Change Proposal Change proposal changes As a result of FBCA Policy Change 2.3 April 15, 2010 James Schminky to 8.1 and 8.4. Proposal Number: 2010-02. Changes Proposal As a result of FBCA Policy Change Changes to 1.3.1.8, Proposal Numbers; 2010-3 thru 8 2.4 March 22, 2011 James Schminky 3.1.1&.2, 3.1.5, 3.2.3.1, and CPCA policy Change Proposal 4.7, 6.1.5, 8.1, and 9.4.3.
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • A Focus on S/MIME
    The University of Saskatchewan Department of Computer Science Technical Report #2011-03 Cryptographic Security for Emails: A Focus on S/MIME Minhaz Fahim Zibran Department of Computer Science University of Saskatchewan Email: [email protected] Abstract In this paper I present a study on \S/MIME", which has become the industry standard for secure email exchange. Based on existing literature review, the study examines S/MIME in depth with specific emphasis on its architecture, strengths, and deficiencies. The study also identifies usability issues related to S/MIME enabled email clients, which indicate scopes for further improvements in those implementations. Obstacles in the adoption of S/MIME are also identified indicating what is required for its successful adoption in the community. In presenting the study, the paper contributes in two ways: (a) for any newcomer in the field of cryptography this paper will be a useful resource to quickly learn about S/MIME in a fair level of detail, (b) the indication about limitations of S/MIME and its implementations reveals an avenue for further research in the area of email security, which may result in improvement of S/MIME itself, or its implementations in the email clients. Keywords: Email Security, S/MIME, MIME, PGP, PKI, Certificate, Email Authentication, Email Encryption, Key Management 1 Introduction Email has been a very common medium of communication these days. It somewhat re- places the traditional surface mail and many of the traditional ways of communication [32]. Today people send and read emails from their personal computers, business workstation, PDAs and even cell phones.
    [Show full text]
  • Towards a Hybrid Public Key Infrastructure (PKI): a Review
    Towards a Hybrid Public Key Infrastructure (PKI): A Review Priyadarshi Singh, Abdul Basit, N Chaitanya Kumar, and V. Ch. Venkaiah School of Computer and Information Sciences, University of Hyderabad, Hyderabad-500046, India Abstract. Traditional Certificate- based public key infrastructure (PKI) suffers from the problem of certificate overhead like its storage, verification, revocation etc. To overcome these problems, idea of certificate less identity-based public key cryptography (ID-PKC) was proposed by Shamir. This is suitable for closed trusted group only. Also, this concept has some inherent problems like key escrow problem, secure key channel problem, identity management overhead etc. Later on, there had been several works which tried to combine both the cryptographic techniques such that the resulting hybrid PKI framework is built upon the best features of both the cryptographic techniques. It had been shown that this approach solves many problems associated with an individual cryptosystem. In this paper, we have reviewed and compared such hybrid schemes which tried to combine both the certificate based PKC and ID-based PKC. Also, the summary of the comparison, based on various features, is presented in a table. Keywords: Certificate-based PKI; Identity-based public key cryptography (ID-PKC); Hybrid PKI 1 INTRODUCTION Public key infrastructure (PKI) and public key cryptography (PKC) [12] plays a vital role with four major components of digital security: authentication, integrity, confidentiality and non-repudiation. Infact, PKI enables the use of PKC through key management. The ”efficient and secure management of the key pairs during their whole life cycle" is the purpose of PKI, which involves key generation, key distribution, key renewal, key revocation etc [11].
    [Show full text]
  • Security Target Document
    Security Target Document Passport Certificate Server Ver. 4.1.1 Prepared for: Common Criteria EAL2 (augmented) 30 April 2002 2225 Sheppard Ave, Suite 1700 Toronto, Ontario, Canada M2J 5C2 TEL: 416-756-2324 FAX: 416-756-7346 [email protected] www.dvnet.com Passport Certificate Server V.4.1.1 Security Target 30 April 2002 Common Criteria EAL 2 (augmented) Version 1.00 TABLE OF CONTENTS 1 Introduction ............................................................................................................................................ 1 1.1 Security Target Identification......................................................................................................... 1 1.2 Security Target Overview............................................................................................................... 1 1.3 Common Criteria Conformance .....................................................................................................1 2 TOE Description..................................................................................................................................... 2 2.1 Product Deployment....................................................................................................................... 2 2.2 Product Functions........................................................................................................................... 2 2.3 Product Description ........................................................................................................................ 3 2.3.1 Platform
    [Show full text]
  • Implementing PKI Services on Z/OS
    Front cover Implementing PKI Services on z/OS Installation of PKI and all of its prerequistes on z/OS An example of the PKI Exit PKI’s use of ICSF to store Master Key Chris Rayns Theo Antoff Jack Jones Patrick Kappeler Vicente Ranieri Roland Trauner ibm.com/redbooks International Technical Support Organization Implementing PKI Services on z/OS February 2004 SG24-6968-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (February 2004) This edition applies to z/OS Version 1, Release 3. © Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this redbook. ix Become a published author . x Comments welcome. xi Chapter 1. Security Server PKI Services. 1 1.1 Overview of digital certificate. 2 1.2 The PKIX standards . 4 1.2.1 CA hierarchy . 6 1.2.2 The X.509 certificate and Certificate Revocation List . 9 1.2.3 The x.509 v3 certificate extension fields . 14 1.2.4 Certificate and CRL appearance. 17 1.3 The z/OS PKI Services . 21 1.3.1 Security Server PKI Services in z/OS . 21 1.3.2 Prerequisite products . 22 1.3.3 Requests supported by z/OS PKI Services. 23 1.3.4 Browser and server certificates. 24 1.3.5 The z/OS PKI Services architecture . 26 1.4 Security Server PKI Services enhancement in z/OS V1R4.
    [Show full text]
  • Amazon Trust Services Certificate Policy
    Certificate Policy Version 1.0.9 1 1 INTRODUCTION ................................................................................................................................................... 13 1.1 Overview ...................................................................................................................................................... 13 1.1.1 Compliance ............................................................................................................................................ 13 1.1.2 Types of Certificates .............................................................................................................................. 13 1.1.2.1 CA-Certificates .............................................................................................................................. 13 1.1.2.1.1 Missing Heading ........................................................................................................................ 14 1.1.2.1.2 Missing Heading ........................................................................................................................ 14 1.1.2.1.3 Terminus CA-Certificates .......................................................................................................... 14 1.1.2.1.4 Policy CA-Certificates ................................................................................................................ 14 1.1.2.1.5 Technically Constrained CA-Certificates ..................................................................................
    [Show full text]
  • A Practical Evaluation of a High-Security Energy-Efficient
    sensors Article A Practical Evaluation of a High-Security Energy-Efficient Gateway for IoT Fog Computing Applications Manuel Suárez-Albela * , Tiago M. Fernández-Caramés , Paula Fraga-Lamas and Luis Castedo Department Computer Engineering, Faculty of Computer Science, Universidade da Coruña, 15071 A Coruña, Spain; [email protected] (T.M.F.-C.); [email protected] (P.F.-L.); [email protected] (L.C.) * Correspondence: [email protected]; Tel.: +34-981-167-000 (ext. 6051) Received: 28 July 2017; Accepted: 19 August 2017; Published: 29 August 2017 Abstract: Fog computing extends cloud computing to the edge of a network enabling new Internet of Things (IoT) applications and services, which may involve critical data that require privacy and security. In an IoT fog computing system, three elements can be distinguished: IoT nodes that collect data, the cloud, and interconnected IoT gateways that exchange messages with the IoT nodes and with the cloud. This article focuses on securing IoT gateways, which are assumed to be constrained in terms of computational resources, but that are able to offload some processing from the cloud and to reduce the latency in the responses to the IoT nodes. However, it is usually taken for granted that IoT gateways have direct access to the electrical grid, which is not always the case: in mission-critical applications like natural disaster relief or environmental monitoring, it is common to deploy IoT nodes and gateways in large areas where electricity comes from solar or wind energy that charge the batteries that power every device. In this article, how to secure IoT gateway communications while minimizing power consumption is analyzed.
    [Show full text]
  • How to Build an X.509 PKI That Works
    How to build a PKI that works Peter Gutmann University of Auckland How to build an X.509 PKI that works Peter Gutmann University of Auckland Preliminaries Whose PKI are we talking about here? •Not SSL certs –Certificate manufacturing, not PKI It’s just an expensive way of doing authenticated DNS lookups with a TTL of one year. Plenty of PK, precious little I — Peter Gutmann on the crypto list •Not PGP, SPKI, *ML, etc –Doing fairly well in their (low-I) area •Not government PKI initiatives –Government IT project reality distortion field, keep pumping in money until it cries Uncle –Even then, the reality distortion has failed in parts of Europe, Australia Preliminaries (ctd) This is PKI for the rest of us •Businesses, individuals, etc Talk covers exclusively technical issues •Policies are someone else’s problem Ted says that whenever he gets asked a religious question he doesn’t understand he always responds with “Ah, that must be an ecumenical matter” which universally produces nods of admiration at the profound wisdom of the statement. It seems that that the PKIX list equivalent is “Ah, that must be a policy matter” — Father Ted (via Anon) •Some religion may sneak in Preliminaries (ctd) Microsoft bashing: An apology in advance •Their PKI software is the most widespread, and features prominently in examples because of this •There is no indication that other software is any better, it just gets less publicity It may be a little controversial… 56th IETF agenda item, submitted as a joke when someone pointed out that PKIX didn’t have any agenda What needs to be done to make PKI work? This forum will be open to all PKIX members, and will constitute a large pool filled knee-deep with custard.
    [Show full text]
  • Security Policies for the Federal Public Key Infrastructure
    Security Policies for the Federal Public Key Infrastructure Noel A. Nazario Security Technology Group National Institute of Standards and Technology Abstract This document discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI). Federal PKI policies deal with the generation, deactivation, and dissemination of public key certificates, the integrity of the infrastructure, maintenance of records, identification of certificate holders, and the establishment of trust relationships between Certification Authorities (CAs). The verification of a digital signature is not sufficient indication of the trustworthiness of an electronic message or data file. The verifier needs to factor the trustworthiness of the CAs involved in the certification of the sender. To accomplish this, the verifier needs to examine the certificate policy for those CAs. The Federal PKI Technical Security Policy establishes guidelines for the operation of Federal CAs and the identification of the parties requesting certification. It also defines Policy Approving Authorities (PAA) responsible for assessing the policies and operational practices of all Federal CAs within a domain and assigning them corresponding Federal Assurance Levels. These assurance levels may be used in lieu of a certificate policy when making an on-line determination of the trustworthiness of a certificate. Key words Certificate policy, Federal Assurance Levels, PAA, PKI, Policy Approving Authority, public key infrastructure, security policy. SECURITY POLICIES FOR THE FEDERAL PUBLIC KEY INFRASTRUCTURE Noel A. Nazario NIST North, Room 426 820 West Diamond Avenue Gaithersburg, MD 20899 [email protected] Introduction and Background This paper discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI).
    [Show full text]
  • Certificate Policy of the Public Key Infrastructure in The
    Certificate Policy of the Public Key Infrastructure in the Deutsche Forschungsnetz - Grid - DFN-Verein Grid-CP V1.4, May 2008 This document and all parts thereof are copyrighted. Distribution or reproduction of the document in unchanged form is explicitly allowed. No transfer of this document, either in whole or in part, into modifiable electronic formats is al- lowed without permission of the DFN-Verein. Contact: [email protected] © DFN-Verein 2008 DFN-Verein - 2 - Grid-CP V1.4 CONTENTS 1 INTRODUCTION.......................................................................................................5 1.1 Overview..........................................................................................................5 1.2 Document name and identification ......................................................................5 1.3 PKI participants ................................................................................................6 1.4 Certificate usage................................................................................................7 1.5 Policy administration .........................................................................................7 1.6 Definitions and acronyms....................................................................................7 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES...................................................7 2.1 Repositories......................................................................................................7 2.2 Publication of certification information..................................................................7
    [Show full text]
  • The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP Antoine Delignat-Lavaud, Inria Paris Joint Work with K
    The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP Antoine Delignat-Lavaud, Inria Paris Joint work with K. Bhargavan, C. Fournet, A. Pionti, P.-Y. Strub INTRODUCTION Introduction Cookie Cutter Virtual Host Confusion Crossing Origin Boundaries Shared Session Cache Shared Reverse Proxies SPDY Connection Pooling Triple Handshake Conclusion Why do we need TLS? 1. Authentication – Must be talking to the right guy 2. Integrity – Our messages cannot be tampered 3. Confidentiality – Messages are only legible to participants 4. Privacy? – Can’t tell who we are and what we talk about Why do we need TLS? 1. Authentication – Must be talking to the right guy Active Attacks 2. Integrity (MitM) – Our messages cannot be tampered 3. Confidentiality – Messages are only legible to participants Passive Attacks 4. Privacy? (Wiretapping) – Can’t tell who we are and what we talk about What websites expect of TLS • Web attacker – Controls malicious websites – User visits honest and malicious sites in parallel – Web/MitB attacks: CSRF, XSS, Redirection… • Network attacker – Captures (passive) and tampers (active) packets What websites expect of TLS • Web attacker – Controls malicious websites – User visits honest and malicious sites in parallel – Web/MitB attacks: CSRF, XSS, Redirection… • Network attacker Strictly stronger – Captures (passive) and tampers (active) packets What websites expect of TLS If a website W served over HTTP is secure against a Web attacker, then serving W over HTTPS makes it secure against a network attacker. What websites expect of TLS If a website W served over HTTP is secure against a Web attacker, then serving W over HTTPS makes it secure against a network attacker.
    [Show full text]