General Information Security Policies
1. General Information Security Policies
1.1 Authority:
Approved by the CEO and CTO of the company.
1.2 Applicability:
Applies to all company staff using computer and communication technologies, including the office network which
accesses, transmits, or stores company information.
1.3 Information security principles
The following information security principles provide overarching governance for the security and management of
information at TRIARE.
1.3.1 Information should be classified according to an appropriate level of confidentiality, integrity and availability and in accordance with relevant legislative, regulatory and contractual requirements.
1.3.2. Staff with particular responsibilities for information must:
- ensure the classification of that information is established;
- must handle that information in accordance with its classification level;
- must abide by any contractual requirements, policies, procedures or systems for meeting those responsibilities.
1.3.3. All users covered by the scope of this policy must handle information appropriately and in accordance with its classification level.
1.3.4. Information should be both secure and available to those with a legitimate need for access in accordance with its classification level.
- Access to information will be on the basis of least privilege and need to know.
1.3.5. Information will be protected against unauthorized access and processing in accordance with its classification level.
1.3.6. Breaches of this policy must be reported
1.3.7. Information security provision and the policies that guide it will be regularly reviewed, including through the use of annual internal audits and penetration testing.
1.4 Information Classification
| Security Level Examples | Definition | Examples |
|---|---|---|
| 1. Confidential | Normally accessible only to specified members of TRIARE. Should be held under private accounts or in an encrypted form. |
|
| 2. Restricted | Normally accessible only to specified and / or relevant members of TRIARE. |
|
| 3. Public | Accessible to all members of the public. |
|
1.5 Responsibilities
C-level of the company: (CEO, CTO, Hear of HR)
Responsible for the security of information produced, provided or held in the course of carrying out research,
consultancy or knowledge transfer activities. This includes ensuring that data is appropriately stored, that the
risks to data are appropriately understood and either mitigated or explicitly accepted, that the correct access
rights have been put in place, with data only accessible to the right people, and ensuring there are appropriate
backup, retention, disaster recovery and disposal mechanisms in place.
Project team members: (Project managers, developers, business analysts, quality engineers, designers)
Responsible for specific area of work, including all the supporting information and documentation that may include
working documents, designs, test plans, SRS documentation, wireframes, estimates, timelines, tasks.
2. Incident Management and Response
This policy forms a part of the company’s data governance framework and supplements existing information security policies. It applies to information security events and incidents affecting any company’s information asset or information system. This policy provides direction in determining the appropriate response to misuse of company information technology (IT) resources from within or outside the company.
TRIARE recognizes the importance of and is committed to effective information security incident management in order to help protect the confidentiality and integrity of its information assets, availability of its information systems and services, safeguard the reputation of the company, and fulfill its legal and regulatory obligations.
This policy applies to all of the following:
- Information – whether in printed, verbal or digital form – created, collected, stored, manipulated, transmitted, or otherwise used in the pursuit of the company’s mission, regardless of the ownership, location, or format of the information.
- Information systems are used in the pursuit of the company’s mission irrespective of where those systems are located.
-
Individuals encountering such information or information systems regardless of affiliation.
The duty to immediately report information security events and incidents is in force at all times; whether the company is open or closed, regardless of the time of day. All staff and contractors must immediately report the following information security events and incidents to TRIARE’s office at support@triare.net.
- All suspected information security events or incidents impacting the confidentiality, integrity, or availability of the company’s data.
- Suspected or actual security breaches of restricted information – whether in printed, verbal or electronic form – or information systems used in the pursuit of the company’s mission.
- Abnormal systematic unsuccessful attempts to compromise restricted information – whether in printed, verbal, or electronic form – or information systems used in the pursuit of the company’s mission.
Suspected or actual weaknesses in the safeguards protecting information or availability of information – whether in printed, verbal, or electronic form – or information systems used in the pursuit of the company’s mission.
- Isolate from the company’s network information systems that are known to be, or suspected of being compromised until the incident has been investigated, resolved, and risks sufficiently mitigated.
- Maintain incident command and communicate with appropriate internal and external entities for incident investigation and resolution.
- Oversee and lead the incident management process to promote a coordinated, consistent, efficient, and effective response.
- Assess information security events and incidents according to the Incident Response Procedure.
- Report incidents involving regulatory matters or restricted data to the company’s CEO and CTO.
Information Security Incident Response Team (ISIRT)
The ISIRT refers to members of OIS who have been identified to be the first responders for information security incidents and will act as the point of contact for information security incidents. The ISIRT will be responsible for the initial response, mitigation support, and (where appropriate) escalation of information security incidents. The primary roles and responsibilities for the ISIRT are as follows:
- Incident Handler – Responsible for the overall management of the incident. Additionally, the Incident Handler will be responsible for fostering cross-team collaboration.
-
Incident Analyst – Responsible for overseeing the technical aspects of the response.
Upon declaration and classification of an incident, ISIRT will notify and escalate information pertaining to the incident. ISIRT will collaborate with other teams and members of the company for incident mitigation and resolution.
Incident Response
The lifecycle of information security incident response and handling is outlined as follows:
- Preparation – writing of incident response policies, training, preparation of appropriate tools, and anything that may be required to handle an information security incident.
- Identification – when events are analyzed in order to determine whether those events might compromise an information security incident.
- Containment – the attempt to keep further damage from occurring as a result of the incident.
- Eradication – the process of understanding the cause of the incident so that the system can be reliably cleaned and ultimately restored to operational status in the following step.
- Recovery – cautiously restoring the system or systems to operational status.
- Lessons Learned – provide a final report on the incident, which will be delivered to management.
3. Server security
3.1 Purpose
The purpose of this policy is to establish standards for the base configuration of internal server equipment that is
owned and/or operated by TRIARE. Effective implementation of this policy will minimize unauthorized access to
proprietary information and technology.
3.2 Scope
This policy applies to server equipment owned and/or operated by TRIARE, and to servers registered under any – owned
internal network domain. This policy is specifically for equipment on the internal network.
3.3 Policy
3.3.1 Ownership and Responsibilities
All internal servers deployed must be owned by an operational group that is responsible for system
administration.
Approved server configuration guides must be established and maintained by each operational group, based on
business
needs.
Operational groups should monitor configuration compliance and implement an exception policy tailored to their
environment. Each operational group must establish a process for changing the configuration guides, which
includes
review and approval by TRIARE
-
Servers must be registered within the corporate enterprise management system. At a minimum, the following information is required to positively identify the point of contact:
- Server contact(s) and location, and a backup contact
- Hardware and Operating System/Version
- Main functions and applications, if applicable
- Information in the corporate enterprise management system must be kept up to date.
- Configuration changes for production servers must follow the appropriate change management procedures.
3.3.2 General Configuration Guidelines
- Operating System configuration should be in accordance with approved TRIARE guidelines.
- Services and applications that will not be used must be disabled where practical.
- Access to services should be logged and/or protected through access-control methods such as TCP Wrappers, if possible.
- The most recent security patches must be installed on the system as soon as practical, the only exception being when an immediate application would interfere with business requirements.
- Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication will do.
- Always use standard security principles of least required access to perform a function.
- Do not use root when a non-privileged account will do.
- If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
- Servers should be physically located in an access-controlled environment.
- Servers are specifically prohibited from operating from uncontrolled cubicle areas.
3.4 Monitoring
-
All security-related events on critical or sensitive systems must be logged and audit trails saved as follows:
- All security-related logs will be kept online for a minimum of 1 week.
- Daily incremental backups will be retained for at least 1 month.
- Weekly full backups of logs will be retained for at least 1 month.
- Monthly full backups will be retained for a minimum of 2 years.
-
Security-related events will be reported to a responsible DevOps engineer, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to:
- Port-scan attacks o Evidence of unauthorized access to privileged accounts
- Anomalous occurrences that are not related to specific applications on the host.
3.5 Compliance
- Audits will be performed on a regular basis by authorized DevOps engineers.
- Audits will be managed by the internal audit group.
- DevOps engineers will filter findings not related to a specific operational group and then present the findings to the appropriate support staff for remediation or justification.
- Every effort will be made to prevent audits from causing operational failures or disruptions.
3.6 Enforcement
Any employee found to have violated this policy may be subject to disciplinary action, up to and including
termination of employment.
4. Network security.
4.1 Purpose
The purpose of this policy is to establish the technical guidelines for IT security and to communicate the controls
necessary for a secure network infrastructure. The network security policy will provide the practical mechanisms to
support TRIARE’s comprehensive set of security policies.
4.2 Scope
This policy covers all IT systems and devices that comprise TRIARE’s network.
4.3 Policy
4.3.1 Network Device Passwords
A compromised password on a network device could have devastating, network-wide consequences. Passwords that are
used to secure these devices, such as routers, switches, and servers, must be held to higher standards than
standard
user-level or desktop system passwords.
4.3.2 Password Construction
The following statements apply to the construction of passwords for network devices:
- Passwords must be at least 12 characters
- Passwords must be comprised of a mix of letters, numbers, and special characters (punctuation marks and symbols)
- Passwords must not be comprised of, or otherwise utilize, words that can be found in a dictionary
- Passwords must not be comprised of an obvious keyboard sequence (i.e., qwerty)
- Passwords must not include “guessable” data such as personal information like birthdays, addresses, phone numbers, locations, etc.
4.3.3 Failed Logons
Repeated logon failures can indicate an attempt to ‘crack’ a password and surreptitiously access a network
account.
When possible, TRIARE will lock accounts after five (5) failed logons. In order to protect against account
guessing,
when logon failures occur the error message transmitted to the user must not indicate specifically whether the
account name or password was incorrect. The error can be as simple as “the username and/or password you supplied
were incorrect.”
4.3.4 Change Requirements
Passwords must be changed according to TRIARE’s Password Policy. Additionally, the following requirements apply
to
changing network device passwords:
- If any network device password is suspected to have been compromised, all network device passwords must be changed immediately.
-
If TRIARE’s network or system administrator leaves the company, all passwords to which the administrator could have had access must be changed immediately.
This statement also applies to any consultant or contractor who has access to administrative passwords.
- Vendor default passwords must be changed when new devices are put into service.
4.3.5 Password Policy Enforcement
Where passwords are used an application must be implemented that enforces TRIARE’s password policies on
construction, changes, re-use, lockout, etc.
4.3.6 Administrative Password Guidelines
As a general rule, administrative (also known as “root”) access to systems should be limited to only those who
have
a legitimate business need for this type of access. This is particularly important for network devices, since
administrative changes can have a major effect on the network, and, as such, network security. Additionally,
administrative access to network devices should be logged.
4.3.7 Logging
The logging of certain events is an important component of good network management practices.
Logging needs vary depending on the type of network system, and the type of data the system holds. The following
sections detail TRIARE’s requirements for logging and log review.
4.3.8 Application Servers
Logs from application servers are of interest since these servers often allow connections from a large number of
internal and/or external sources. These devices are often integral to smooth business operations.
Examples: Web, email, database servers
Requirement: At a minimum, logging of errors, faults, and login failures is required. Additional logging is
encouraged as deemed necessary. No passwords should be contained in logs.
4.3.9 Network Devices
Logs from network devices are of interest since these devices control all network traffic, and can have a huge
impact on TRIARE’s security.
Examples: Firewalls, network switches, routers
Requirement: At a minimum, logging of errors, faults, and login failures is required. Additional logging is
encouraged as deemed necessary. No passwords should be contained in logs.
4.3.10 Critical Devices
Critical devices are any systems that are critically important to business operations. These systems may also
fall
under other categories above – in any cases where this occurs, this section shall supersede.
Examples: File servers, lab machines, systems storing intellectual property
Requirements: At a minimum, logging of errors, faults, and login failures is required. Additional logging is
encouraged as deemed necessary. No passwords should be contained in logs.
4.3.11 Log Management
While logging is important to TRIARE’s network security, log management can become burdensome if not implemented
appropriately. As logs grow, so does the time required to review the logs. For this reason, the company
recommends
that a log management application be considered.
4.3.12 Log Review
Device logs do little good if they are not reviewed on a regular basis. Log management applications can assist
in
highlighting important events, however, a member of TRIARE’s IT team, or the Countywide Elected Officials IT
Team,
depending on the responsibility of said system, should still review the logs as frequently as is reasonable.
4.3.13 Log Retention
Logs will be retained for a minimum of 30 days. Logs should be considered operational data.
4.3.14Firewalls
Firewalls are arguably the most important component of a sound security strategy. Internet connections and other
unsecured networks must be separated from TRIARE’s network through the use of a firewall.
4.3.15 Configuration
The following statements apply to TRIARE’s implementation of firewall technology:
- Firewalls must provide secure administrative access (through the use of encryption) with management access limited, if possible, to only networks where management connections would be expected to originate.
- No unnecessary services or applications should be enabled on firewalls. TRIARE uses ‘hardened’ systems for firewall platforms or appliances.
- Clocks on firewalls must be synchronized with TRIARE’s other networking hardware using NTP or another means. Among other benefits, this will aid in problem resolution and security incident investigation.
- The firewall ruleset must be documented and audited periodically. Audits must cover each rule, what it is for, if it is still necessary, and if it can be improved.
- For its own protection, the firewall ruleset must include a “stealth rule,” which forbids connections to the firewall itself.
- The firewall must log dropped or rejected packets.
4.3.16 Outbound Traffic
Filtering Firewalls are often configured to block only inbound connections from external sources; however, by
filtering outbound connections from the network, security can be greatly improved. This practice is also
referred to
as “Egress Traffic Filtering.” Blocking outbound traffic prevents users from accessing unnecessary, and many
times,
dangerous services. By specifying exactly what outbound traffic to allow, all other outbound traffic is blocked.
This type of filtering would block rootkits, viruses, and other malicious tools if a host were to become
compromised. This will also prevent remote desktops from accessing the internal network. TRIARE encourages
outbound
filtering if possible, but it is not required. If filtering is deemed possible, only the following known “good”
services should be permitted outbound from the network: 21, 22, 23, 25, 53, 80, 110, 443, and 995.
4.3.17 Networking Hardware
Networking hardware, such as routers, switches, hubs, bridges, and access points, should be implemented in a
consistent manner. The following statements apply to TRIARE’s implementation of networking hardware:
- Networking hardware must provide secure administrative access (through the use of encryption) with management access limited, if possible, to only networks where management connections would be expected to originate.
- Clocks on all network hardware should be synchronized using NTP or other means. Among other benefits, this will aid in problem resolution and security incident investigation.
- If possible for the application, switches are preferred over hubs. When using switches the County should use VLANs to separate networks if it is reasonable and possible to do so.
- Access control lists should be implemented on network devices that prohibit direct connections to the devices. Exceptions to this are management connections that can be limited to known sources.
- Unused services and ports should be disabled on networking hardware.
- Access to administrative ports on networking hardware should be restricted to known management hosts and otherwise blocked with a firewall or access control list.
4.4 Intrusion Detection/Intrusion
Prevention Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) technology can be useful in
network monitoring and security. The tools differ in that an IDS alerts to suspicious activity whereas an IPS blocks
the activity. When tuned correctly, IDSs are useful but can generate a large amount of data that must be evaluated
for the system to be of any use. IPSs automatically take action when they see suspicious events, which can be both
good and bad since legitimate network traffic can be blocked along with malicious traffic.
TRIARE requires the use of both an Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) on critical
or high-risk network segments. Procedures must be implemented to review and act on the alerts expediently. For the
IPS, procedures must be implemented that provides a mechanism for emergency unblocking if the IPS obstructs
legitimate traffic. The IPS must be audited and documented according to the standards detailed in the “Firewalls”
section of this document.
5. Vulnerabilities.
5.1 Purpose
The purpose of this policy is to establish standards for the systematic penetration testing of the company’s
servers, software, and network devices.
5.2 Scope
This policy applies to server equipment owned and/or operated by TRIARE, and to servers registered under TRIARE’s
organization.
5.3 Policy
5.3.1 Penetration testing should be performed once every half a year according to the testing plan developed and implemented by the responsible DevOps engineer. The plan should be presented for review and approval to TRIARE’s CTO.
5.3.2 The tools provided by kali.org will be used to validate policies and processes described in this document. Tools will be used in accordance with the needs of the penetration test. Details will be included in the testing plan.
5.3.3. The results of the penetration testing should be reflected in the report and presented to the company’s CTO.
5.3.4. In the case with unsatisfactory results the actions to be taken to correct the faults.