78 What Every Engineer Should Know About Cyber Security
Example Policy
1. Introduction
is acceptable use policy (AUP) for IT Systems is designed to protect <Company X>, our
employees, customers, and other partners from harm caused by the misuse of our IT systems
and our data. Misuse includes both deliberate and inadvertent actions.
e repercussions of misuse of our systems can be severe. Potential damage includes, but is
not limited to, malware infection (e.g., computer viruses), legal and fi nancial penalties for data
leakage, and lost productivity resulting from network downtime.
Everyone who works at <Company X> is responsible for the security of our IT systems and the
data on them. As such, all employees must ensure they adhere to the guidelines in this policy at
all times. Should any employee be unclear on the policy or how it impacts his or her role, he or
she should speak to his or her manager or IT security offi cer.
2. Defi nitions
“Users” are everyone who has access to any of <Company X>’s IT systems. is includes permanent
employees and also temporary employees, contractors, agencies, consultants, suppliers, customers,
and business partners.
“Systems” means all IT equipment that connects to the corporate network or accesses corporate
applications. is includes, but is not limited to, desktop computers, laptops, smartphones,
tablets, printers, data and voice networks, networked devices, software, electronically stored
data, portable data storage devices, third-party networking services, telephone handsets, video
conferencing systems, and all other similar items commonly understood to be covered by this
term.
3. Scope
is is a universal policy that applies to all users and all systems. For some users and/or some
systems, a more specifi c policy exists. In such cases, the more specifi c policy has precedence in
areas where they confl ict, but otherwise both policies apply on all other points.
is policy covers only internal use of <Company X>’s systems and does not cover use of our
products or services by customers or other third parties.
Some aspects of this policy aff ect areas governed by local legislation in certain countries
(e.g.,employee privacy laws). In such cases, the need for local legal compliance has clear prece-
dence over this policy within the bounds of that jurisdiction. In such cases, local teams should
develop and issue users with a clarifi cation of how the policy applies locally.
Staff members at <Company X> who monitor and enforce compliance with this policy are
responsible for ensuring that they remain compliant with relevant local legislation at all times.
4. Use of IT Systems
All data stored on <Company X>’s systems is the property of <Company X>. Users should be
aware that the company cannot guarantee the confi dentiality of information stored on any
<Company X> system except where required to do so by local laws.
<Company X>’s systems exist to support and enable the business. A small amount of
personal use is, in most cases, allowed. However, it must not be in any way detrimental to users’
own or their colleagues’ productivity, nor should it result in any direct costs being borne by
<CompanyX> other than for trivial amounts (e.g., an occasional short telephone call).
FIGURE 4.5
Sophos example IT AUP (http://www.sophos.com).
79Preparing for an Incident
<Company X> trusts employees to be fair and sensible when judging what constitutes an
acceptable level of personal use of the company’s IT systems. If employees are uncertain, they
should consult their manager.
Any information that is particularly sensitive or vulnerable must be encrypted and/or securely
stored so that unauthorized access is prevented (or at least made extremely diffi cult). However,
this must be done in a way that does not prevent—or risk preventing—legitimate access by all
properly authorized parties.
<Company X> can monitor the use of its IT systems and the data on it at any time. is may
include (except where precluded by local privacy laws) examination of the content stored within
the e-mail and data fi les of any user, and examination of the access history of any users.
<Company X> reserves the right to audit networks and systems regularly to ensure compliance
with this policy.
5. Data Security
If data on <Company X>’s systems is classifi ed as confi dential, this should be clearly indicated
within the data and/or the user interface of the system used to access it. Users must take all
necessary steps to prevent unauthorized access to confi dential information.
Users are expected to exercise reasonable personal judgment when deciding which
information is confi dential.
Users must not send, upload, remove on portable media, or otherwise transfer to a
non-<Company X> system any information that is designated as confi dential, or that they should
reasonably regard as being confi dential to <Company X>, except where explicitly authorized to
do so in the performance of their regular duties.
Users must keep passwords secure and not allow others to access their accounts. Users must
ensure all passwords comply with <Company X>’s safe password policy.
Users who are supplied with computer equipment by <Company X> are responsible for the
safety and care of that equipment and the security of software and data stored on it and on other
<Company X> systems that they can access remotely using it.
Because information on portable devices, such as laptops, tablets, and smartphones, is
especially vulnerable, special care should be exercised with these devices: Sensitive information
should be stored in encrypted folders only. Users will be held responsible for the consequences
of theft of or disclosure of information on portable systems entrusted to their care if they have
not taken reasonable precautions to secure it.
All workstations (desktops and laptops) should be secured with a lock-on-idle policy active
after, at most, 10 minutes of inactivity. In addition, the screen and keyboard should be manually
locked by the responsible user whenever leaving the machine unattended.
Users who have been charged with the management of those systems are responsible for
ensuring that they are at all times properly protected against known threats and vulnerabilities
as far as is reasonably practicable and compatible with the designated purpose of those
systems.
Users must, at all times, guard against the risk of malware (e.g., viruses, spyware, Trojan
horses, rootkits, worms, backdoors) being imported into <Company X>’s systems by whatever
means and must report any actual or suspected malware infection immediately.
FIGURE 4.5 (Continued)
80 What Every Engineer Should Know About Cyber Security
the device they are bringing to work. They are also updating their
devices to the latest and greatest technology much sooner than the
organization would.
Cons: The company is losing control over the hardware and how the
devices are utilized. The AUP and compliance mandates are more
difcult to enforce since the device is not company owned. There is
also the issue of when the employee separates from the company:
The company wants its data back! This will get very tricky if there
is a lawsuit involved; the employee may think that his or her phone
does not need to be examined, but that is probably not the case. This
risk needs to be explained to employees participating in a BYOD
program.
Mobile phones are the most popular device to bring. Most mobile
devices, especially user-owned mobile devices, can be untrustworthy
and do not have many of the trust features that are built into hosts and
laptops (Souppaya and Scarfone 2012). NIST (2012) suggests running the
6. Unacceptable Use
All employees should use their own judgment regarding what is unacceptable use of
<CompanyX>’s systems. e activities below are provided as examples of unacceptable use;
however, the list is not exhaustive. Should an employee need to contravene these guidelines in
order to perform his or her role, the employee should consult with and obtain approval from his
or her manager before proceeding:
• All illegal activities. ese include theft, computer hacking, malware distribution,
contravening copyrights and patents, and using illegal or unlicensed software or services.
ese also include activities that contravene data protection regulations.
• All activities detrimental to the success of <Company X>. ese include sharing sensitive
information outside the company, such as research and development information and
customer lists, as well as defamation of the company.
• All activities only for personal benefi t that have a negative impact on the day-to-day
functioning of the business. ese include activities that slow down the computer
network (e.g., streaming video, playing networked video games).
• All activities that are inappropriate for <Company X> to be associated with and/or are
detrimental to the company’s reputation. ese include pornography, gambling, inciting
hate, bullying, and harassment.
• Circumventing the IT security systems and protocols that <Company X> has put in place.
7. Enforcement
<Company X> will not tolerate any misuse of its systems and will discipline anyone found to
have contravened the policy, including not exercising reasonable judgment regarding acceptable
use. While each situation will be judged on a case-by-case basis, employees should be aware that
consequences may include the termination of their employment.
Use of any <Company X>’s resources for any illegal activity will usually be ground for summary
dismissal, and <Company X> will not hesitate to cooperate with any criminal investigation and
prosecution that may result from such activity.
FIGURE 4.5 (Continued)
81Preparing for an Incident
organization’s software in a secure state (in isolation from the rest of the
device’s applications and data) on the mobile phone or utilizing integrity
scanning applications for that specic device. Important factors when
developing a mobile device security policy include: sensitivity of the work,
level of condence in security policy compliance, cost, work location, tech-
nical limitations (if the device needs to be able to run a particular appli-
cation), and compliance with mandates and other policies (Souppaya and
Scarfone 2012).
Other things to consider when writing a BYOD policy (Hassell 2012)
include:
1. Specify what devices are permitted and supported by the
organization.
2. Establish a stringent security policy for all devices, such as a com-
plex password attached to the device.
3. Dene a clear service policy for devices under BYOD criteria,
such as support for applications, broken devices, initial connec-
tions, etc.
4. Make it clear who owns which applications and data because if the
device becomes lost or stolen, the company may wipe the device for
security reasons—thus, personal data will be gone. Possibly provide
information to the employee regarding backing up his or her own
content.
5. Decide which applications will be allowed or banned. More than
a few mobile device applications have vulnerabilities.
6. Integrate your BYOD plan with your AUP. Address social network-
ing, viewing objectionable websites, and how its use will be moni-
tored while a device is connected to the corporate network.
7. Set up an employee exit strategy to address how access tokens,
e-mail access, data, and proprietary applications and information
will be removed.
4.6 Establishing an Incident Response Team
Why do we need to establish a response team?
There is no question that computer incidents are on the rise and
that organizations need all the help they can get to be pre-
pared. The computer incident response team (CIRT) is the much
needed point of contact when an incident occurs. The CIRT can
help determine the incident’s impact on the organization as
82 What Every Engineer Should Know About Cyber Security
well as perform tasks that can mitigate the damage and get the
organization up and running again. They can also help with risk
assessment, offer lessons learned, and help with training.
Who should be on the CIRT?
Depending on the needs of the organization, the team can consist of
employees, be fully outsourced, or be a combination of the two.
This choice will depend on the organization’s resources and needs.
NIST has written a “Computer Security Incident Handling Guide”
(Cichonski et al. 2012) that addresses the CIRT. It contains CIRT
recommendations that address what factors need to be considered,
how to establish the team, when to contact stakeholders, etc.:
− Establish a formal incident response capability to be prepared
when there is a breach.
− Create an incident response policy to dene “incidents,”
roles, and responsibilities, etc.
− Develop an incident response plan based on the inci-
dent response policy. Also, establish metrics to assess the
program and how training should occur.
− Develop incident response procedures that detail the step-
by-step process of responding to an incident.
− Establish policies and procedures regarding incident-
related information sharing such as media, law enforcement,
etc. The team needs to consult with the organization’s legal
department, public affairs, and management to determine
the policy and procedure.
− Provide pertinent information on incidents to the appro-
priate organization, such as the US-CERT for federal civilian
agencies and/or ISAC organizations who use data to report
threats and incidents.
− Consider the relevant factors when selecting an incident
response team model to construct the most effective team
structure (e.g., to outsource or not) for the organization.
− Select people with appropriate skills for the incident
response team. In addition to technical skills, being able to
effectively communicate should be a requirement.
− Identify other groups within the organization that may need
to participate in incident handling, such as management,
legal, facilities, etc.
− Determine which services the team should offer in addi-
tion to incident response, such as monitoring intrusion detec-
tion sensors, disseminating information regarding security
threats, and educating users on the security policies.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.