Information Security Solutions
Below is a list of tools, devices, and protocols utilized for protecting our networks. The following list is considered vital when it comes to Cinchy's information security best practices:
Network Devices: Firewall, routers, switches, load balancers, intrusion detection systems (IDS).
Malware Solutions: anti-virus and anti-spam software and devices.
File Integrity Monitoring (FIM) and change detection software, host-based intrusion detection, and intrusion prevention devices.
Secure services – those that are operating system (O/S) and application-specific to all major operating systems (Windows, UNIX, Linux) and applications (web server applications, database applications, internally developed applications).
Secure protocols, such as SSL/TLS, SSH, VPN, etc.
Secure ports, such as 443, 22, etc.
User access principles, such as Role Based Access Controls (RBAC), etc.
Username and password parameters, such as unique user ID's, password complexity rules, password aging rules, account lockout thresholds, etc.
Event monitoring.
Configuration and change monitoring.
Performance and utilization monitoring.
Logging and reporting.
Appropriate incident response measures.
Software Development Life Cycle (SDLC)
The Software Development Life Cycle (SDLC) for Cinchy encompasses a number of phases, each concluding with a major milestone. Assessments are conducted after each phase to determine if objectives have been satisfied. Material changes within the development phases are controlled through the process set forth in the Configuration and Change Management Policy. Skilled software engineers are utilized throughout all phases, which results in a thorough and uninterrupted process from beginning to end.
The development/test environment and the production environment are appropriately segregated. Development uses multiple separate environments that stage into production to ensure that untested code is not released in the primary system. Multiple safeguards exist to ensure that data and code are not compromised at each stage of the development pipeline.
SDLC activities for internally-developed systems/applications consist of the following procedures and phases:
Request for New System/Application or Features. The process begins with the request for a new system/application, feature, or tool. Authorized personnel will initiate the request. All requests are to be appropriately logged in Cinchy.
Feasibility Study. Once a request for a new system/application, feature or tool is received, Cinchy analyzes it and evaluates its market opportunity and/or operational impact. Once the benefits are identified, Cinchy conducts a feasibility study with the assistance of the development team.
Estimate and HW/SW Requirements. Along with estimating the effort and time required to implement the new system/application, feature or tool, an estimate of hardware and software required for development and final deployment is conducted.
Management Decision. After reviewing the business rationale for the new system/application, feature, or tool, Cinchy decides whether the cost/benefits and strategic direction warrant the development to proceed. A review of the business rationale for a completely new project includes studying market opportunity and conducting a competitive analysis. As soon as the project receives approval, the process progresses to the development and deployment phases.
Requirement Analysis. During this phase, a detailed requirements analysis of the new system/application, feature, or tool is conducted and documented in the form of a requirements specification. Documents and activities for this phase include obtaining copies of documents used during this phase and interviewing personnel for major activities during this phase.
In this phase, various technical personnel collaborate to develop a detailed design of the various activities involved. The design and development team will review the design, and the final version is documented in the form of a design specifications document. If the feature or tool is to be a part of an existing system/application or functionality, the existing design document may be modified in lieu of creating a new document. Test plans and procedures for system tests are also developed.
Once the design is finalized, the actual implementation of the system/application, feature, or tool begins with a test in a development environment. After all errors found during the testing stage are corrected, the application code is released to a test server.
Code Review. Secure code review is the single-most effective technique for identifying security bugs early in the system development lifecycle. Code is reviewed by individuals other than the originating code author, and by individuals knowledgeable about code review techniques and secure coding practices. Code Review is the process of auditing the source code to verify the following requirements
the proper security and logical controls are present,
that they work as intended
that they have been invoked in the right places, and
code is developed according to secure coding guidelines
Static Code Analysis. Static Code Analysis is carried out during the implementation phase. Cinchy runs a static code analysis tool that identifies possible vulnerabilities within the 'static' (non-running) source code. Bugs may exist in the application due to insecure code, design, or configuration.
Quality Assurance and Testing. Once all the modules are moved to a test server and integrated into the test environment, any necessary test database tables and stored procedures are also created on the test server(s). The test environment is configured as a replica of the production environment or a specific client environment; however, there may be external interfaces which, at times, may not be duplicated, and approximations may be used. Testers then assess the new modules in this test environment. Test cases and scripts are written and documented as required. Any discrepancies are resolved with the development team, and any other additional testing is conducted. Customers and/or third-party users may be involved at different levels in this phase of the project cycle, based on a mutual understanding of verification requirements. Test results are documented and reviewed with development personnel and management for final approval.
Release Decision Once a release candidate is ready, the Change Control Board and the Engineering Team review the list of features and risk for that release candidate. After final approval, the build is published for customers and approved for releasing to our internal Cinchy production environment.
Release for Production. Once the system/application, feature, or tool is successful in the test environment, Cinchy approves the release for production. Modules are moved to the production servers where functionality is tested after all modules are updated.
Production Monitoring. Once the system/application, feature or tool is released into production, it is monitored for the first hour, and then for a day, and then a week.
All necessary system patches and system updates to Cinchy system components (those defined as critical from a security perspective) are to be obtained and deployed in a timely manner as designated by the following software vendor and/or other trusted third-parties:
Vendor websites and email alerts.
Vendor mailing lists, newsletters, and additional support channels for patches and security.
Third-party websites and email alerts.
Third-party mailing lists.
Approved online forums and discussion panels.
Effective patch management and system updates help ensure the confidentiality, integrity, and availability (CIA) of systems from new exploits, vulnerabilities, and other security threats.
The timeline for applying patches depends on the severity level of the vulnerability. Cinchy uses the following timelines for patch management based on severity level:
Critical - Immediately to 7 days from identification.
High - within 30 days of identification.
Medium and Low - should be identified, tracked, and a timeline established.
Patches fixing highly critical or zero-day vulnerabilities are to be escalated and applied as soon as possible.
Once an employee has identified a critical or zero-day vulnerability, they should report the vulnerability immediately to the CTO. The CTO will consider the following factors on when to apply the patch.
The relative importance of the vulnerable systems.
The relative severity of each vulnerability.
The operational risks of patching without first performing thorough testing.
Whether there is a viable option to mitigate the vulnerability through an alternative method, at least until patches are fully deployed and operational.
Additionally, all patch management initiatives are to be documented accordingly, which shall include information relating to the personnel responsible for conducting patching, list of sources used for obtaining patches and related security information, the procedures for establishing a risk ranking for patches, and the overall procedures for obtaining, deploying, distributing, and implementing patches specifically related to Cinchy system components.
Various external security sources and resources are to be utilized for ensuring that Cinchy maintains awareness of security threats, vulnerabilities, and what respective patches, security upgrades, and protocols are available. Authorized I.T. personnel are to subscribe to the following types of security sources and resources for ensuring retrieval of security patches in a timely manner:
Vendor websites and email alerts, such as those for Microsoft, UNIX, Linux, Cisco, HP, etc.
Approved third-party websites, email alerts, and mailing lists.
Approved online information security forums and discussion panels.
Information security conferences, seminars, and trade shows.
Community driven platforms relating to vulnerability management of information system, such as the following MITRE websites, and many others:
Open Source Vulnerability Database (OSVDB)
Common Configuration Enumeration (CCE)
Common Vulnerabilities and Exposures (CVE)
Common Platform Enumeration (CPE)
Common Weakness Enumeration (CWE)
Malware (MAEC)
Cyber Observables (CyboX)
Structured Threat Information Expression (STIX)
Trusted Automated Exchange of Indicator Information (TAXII)
Making Security Measurable (MSM)
Open Vulnerability and Assessment Language (OVAL)
Common Attack Pattern Enumeration and Classification (CAPEC)
More detail is discussed in Cinchy's Change and Configuration Management Policy, which is incorporated here by reference. Cinchy in particular monitors for CVE's and patches from:
The National Vulnerability Database (NIST)
Cloud Environment
Performance and Security Testing
All applicable Cinchy system components are to undergo annual vulnerability assessments along with penetration testing for ensuring their safety and security from the large and ever-growing external and internal security threats being faced with today. Vulnerability assessments, which entails scanning a specified set of network devices, hosts, and their corresponding Internet Protocol (IP) addresses, helps identify security weaknesses within Cinchy's network architecture, along with those related to specific system components. Additionally, penetration testing services, which are designed to actually compromise the organization's network and application layers, also assist in finding security flaws that require immediate remediation. Moreover, contractual requirements, along with regulatory compliance laws and legislation, often mandate organizations to perform such services, at a minimum, annually (for penetration tests), and often on a periodic and/or quarterly basis (for vulnerability assessments). Vulnerability scans are performed after any significant change. As such, Cinchy will adhere to these stated requirements and will perform the necessary services on all applicable system components with an appropriately independent team.
Careful planning and consideration of what systems are to be included when performing vulnerability assessments and, particularly, penetration testing, is a critical factor, as all environments (i.e., development, production, etc.) must be safeguarded from any accidental or unintended exploits caused by the tester.
Additionally, for Cinchy's internally developed, proprietary applications (i.e., software), appropriate code reviews are to be conducted for ensuring the software itself has been coded and developed with the appropriate security measures. Poorly coded software, specifically software used for web-facing platforms, can be compromised through numerous harmful tactics, such as Cross-site scripting (XSS), injection flaws (SQL, etc.), and other damaging methods.
Cinchy also runs periodic automated security vulnerability scans on its systems by contracting with third-parties.
Encryption Standards
Cinchy requires that the following list of industry-leading security standards, benchmarks, and frameworks are utilized:
Ciphers in use must meet or exceed the set defined as "AES-compatible" or "partially AES-compatible" according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.
Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.
In general, Cinchy adheres to the NIST Policy on Hash Functions.
Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).
Endpoints must be authenticated prior to the exchange or derivation of session keys.
Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.
All servers used for authentication (for example, RADIUS or TACACS) must have installed a valid certificate signed by a known trusted provider.
All servers and applications using TLS must have the certificates signed by a known, trusted provider. Only TLS 1.2+ is permitted. TLS must be configured according to the OWASP recommendations in their TLS Cheat Sheet.
Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise.
Key generation must be seeded from an industry-standard random number generator (RNG). For examples, see NIST Annex C: Approved Random Number Generators for FIPS PUB 140-2