Scribd
Upload
2 views

Annex A Controls

27001

Uploaded by

8d4gnwyfr7
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
2 views

Annex A Controls

27001

Uploaded by

8d4gnwyfr7
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Annex A 8.1 User Endpoint Devices?

1. Have policies and procedures in place


Write, approve, implement and communicate the documentation
required for user end point devices.
2. Assess your equipment and perform a risk assessment
Have an asset management process that includes an asset register.
For each asset type perform a risk assessment. Based on the risk
assessment implement the appropriate controls to mitigate the risk
3. Keep records
For audit purposes you will keep records. Examples of the records to
keep include changes, updates, monitoring, review and audits.
4. Test the controls that you have to make sure they are working
Perform internal audits that include the testing of the controls to
ensure that they are working.

What the auditor will check


The audit is going to check a number of areas for ISO27001 Annex A
8.1 User Endpoint Devices. Lets go through the main ones:
1. That you have an asset register
The auditor will check that you have an asset register and an asset
management process. They will want to see all of the end point
devices in an asset register and that they are assigned to people. For
this they are also wanting to see bring your own devices (BYOD) or
people’s own devices that connect to or interact with the in scope
services.
2. That devices are protected and checked
The auditor is going to check that all the appropriate controls are on
the end point device with the usual ones being antivirus and
encryption. The SOA and the in scope controls is the starting point
and specifically the technical controls that you have said are in scope.
They want to see that these are checked periodically with evidence of
the checks and they also want to see what you do if the checks fail,
with evidence of an example of that. This is covered in more depth
in ISO27001 Annex A Control 5.9 Inventory of information and other
associated assets.
A great one here is that they will also check that you check that
devices used by auditors and testers as part of verification activities
are secure to your standards before allowing them to connect. This is
covered in more detail in ISO27001 Annex A 8.34 Protection of
information systems during audit testing
3. Anyone they audit
They will likely check anyone that they audit. The usual operating
approach is to get the person to share their screen and then to direct
them to show the technical controls in place. This is usually ‘show me
the antivirus is working’ as an approach. It is less common for them to
observe the desk top and the trash for evidence of things that should
not be there. You really should get everyone that is being audited to
perform house keeping before the audit with the assumption they will
be asked to share their screen. You can refuse and base that on
confidentiality but they will want to see a sample of devices so if not
you, then it will be someone.
A 8.2 Privileged Access Rights
How to comply with ISO 27001 Annex A 8.2
1. Have policies and procedures in place
Write, approve, implement and communicate the documentation
required for privileged access rights.
2. Assess your privilege use requirements and perform a risk
assessment
Identify what your requirements are for privileged access and then
perform a risk assessment.
3. Implement controls proportionate to the risk posed
Based on the risk assessment implement controls proportionate that
risk assessment and the needs of the business.
4. Keep records
For audit purposes you will keep records. Examples of the records to
keep include changes, updates, monitoring, review and audits.
5. Test the controls that you have to make sure they are working
Perform internal audits that include the testing of the controls to
ensure that they are working.

Top 3 Mistakes People Make for ISO 27001


Annex A 8.2
The top 3 mistakes people make for ISO 27001 Annex A 8.2 are
1. Having generic accounts
Having generic accounts is not always a bad thing but having them
because you are lazy is. Try to eliminate them and where you do
require them manage via risk management. This means recording
them on the risk register and managing the risk, even if managing the
risk is accepting the risk and recording the decision.
2. Laptop Administrator Accounts
This common mistake actually relates to end points and the default
position of providing all users administrative control over those
devices by default. Again, this is usually lazy management and again,
as above, if required manage it via risk management. Auditors check
and will want a justification and don’t just do it because it is easy or
you have always done it. This level of access really does negate a lot
of the end point controls that you are going to rely on.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that
version numbers match where used, having a review evidenced in the
last 12 months, having documents that have no comments in are all
good practices.

A 8.3 Information Access


Restriction
1. Not restricting access when people leave
Having a robust starter, leaver, mover process that accounts for
leavers and considers the access restrictions during the notice period
as well as when the person leaves is key. This is often overlooked
with people having full access during notice and often the access still
being in place when they leave.
2. Not matching your classification policy
The access policy and the classification policy set out what you do,
not how you do it. Often there is an mis match with what actually
happens. Consider approaches like role based access that allow you
to define the access restriction requirements and then monitor, report
and audit against it.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that
version numbers match where used, having a review evidenced in the
last 12 months, having documents that have no comments in are all
good practices.

A 8.4 Access To Source Code


How to implement ISO 27001 Annex A 8.4
Applicability
If you have source code then you want to protect access to it. If you
do not then this is not in scope for you, you can update your statement
of applicability to put it out of scope, add it to the risk register and
accept the risk.
Documentation
If you do have source code then you already know what to do as there
is nothing revolutionary in this particular control. The control is looking
for documentation and maturity of process of what you already do.
Process
You are going to manage access to your source code, program code,
libraries and associated software. The requirement is to stop
unauthorised modification that can lead to an information security
incident.
Risk Assessment
Conduct a risk assessment, understand what you have and what you
need to protect and put in place appropriate controls around that.
Logging and Monitoring
It is good practice to include logging and monitoring so you have audit
trails.
Digital Signatures
Digital signatures may or may not be required as part of the process of
providing assurance on the integrity of the code and you may find
some clients require the use of escrow services.

The top 3 mistakes people make for ISO 27001 Annex A 8.4 are
1. Allowing everyone to access code
Depending on the size of teams, complexity and mix of internal and
external resource the requirements for access restrictions on code can
often get over looked. Be sure to understand and document the
requirements, put in place processes and lock the access down based
on organisation need and business risk.
2. Your code is on laptops
This common mistake actually relates to copies of your code being all
over the place. It can be hard to manage code and developers and
teams to maintain a single source of truth in a controlled way that
protects your intellectual property and the integrity of the code base.
Some people use check in and check out solutions but be aware of
rogue copies of your code out in the real world and the risk it poses to
you, usually in terms of that code being taken and used some where
else for commercial gain without your approval or knowledge.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that
version numbers match where used, having a review evidenced in the
last 12 months, having documents that have no comments in are all
good practices.

A 8.5 Secure Authentication


Top 3 Mistakes People Make for ISO 27001
Annex A 8.5
The top 3 mistakes people make for ISO 27001 Annex A 8.5 are
1. Password management is flaky
This usual things here that go wrong are when people always use the
same default passwords for users. They set it and then the user
doesn’t change it. Ideally set a new ‘starting’ password for each users.
We see these then being shared over email or text in clear text. If you
simply must do this then consider sending user names and passwords
over different channels. If email gets compromised having the user
name and passwords in emails means people have an easy hop then
to breach your other systems.
2. Authentication is weak
Having weak authentication, like little to no requirements on the type
of password people use, means life is easy for everyone but these are
also easy to compromise, breach, hack, guess. There has to be a
balance. Having no passwords or easy default passwords that never
expire is one approach but try to find a middle ground. If you are not
NASA then bio metrics maybe overkill, I get it. Be sure to have
something.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that
version numbers match where used, having a review evidenced in the
last 12 months, having documents that have no comments in are all
good practices.

You might also like