Article

Why get a ninja to sail your pirate ship?

Information security guidance for Project Managers

In the modern corporate environment it is quite likely that all projects relate to information security in some shape or form, and, as a result, could put the company at risk if they are not handled correctly. As a result, your company’s Information Security Manager (ISM) might be very interested in how your project is being managed. Something that a Project Manager may consider to be ‘useless’ information could be the key to an attack that a hacker has been planning for months. Do you want your project to provide the loophole that lets them in?

This article is written to help you as a Project Manager to understand how security requirements may affect your project, how to understand if you have a need for security testing, what is at risk and where to go in your organisation to get guidance and support. It will assist you in planning your project effectively and make the world of information security seem a bit less scary and intimidating.

Let me give you just one initial example of the importance of information security. You have been provided with a PID to setup a website that allows users to register and receive alerts about upcoming events. As part of their registration, they enter their preferences and information about themselves. Whilst you are planning your project, you are working out who is going to develop it, how much time it will take, what it costs and putting your plan and project team together. Have you considered security as part of your project? In most cases the answer would be no. However, if you consider the information you will be receiving and storing, including email addresses, passwords and personal preferences, this information could be of value to a malicious attacker. Security should be discussed as part of the initiation and planning phases of your project.

Now we know that companies come in all shapes and sizes, and we’re making a few assumptions about your organisation. If these don’t apply to you, don’t worry but please read on, because a lot of the advice and guidance will still stand. Additionally, in the conclusion, we offer advice to those who do not have these elements in place.

So, we think your company looks a bit like this, although you may not realise at this point:

  • Your company has an Information Security Manager (ISM) who is responsible for protecting the company’s key information assets
  • Your company has security policies in place or perhaps has ISO27001 accreditation (the International Standard for an Information Security Management System)
  • Your company has an established security partner. A security partner is an external company that provides your company with advice, guidance and testing services to help improve its security

Process

Like us, you probably believe that good project management is all about anticipation and being proactive, and that’s certainly true here. Before your company’s Information Security Manager comes knocking on your door asking you what security considerations you have made to your project, get a step ahead of them and find out what you need to do early on. A good place to start would be:

  • Find out who is responsible for information security and how they interact with projects within your organisation
  • Investigate your company security policies on your intranet (common names are Security Guidance, Information Security Policy, Business Risk Policy, etc.)
  • See if there are any documents referring to security risk and what types of information are important to the organisation
  • Check if there is a Software Development LifeCycle (SDLC) in place

If you are new to information security, it’s likely that everything will initially sound a bit scary and overwhelming. Don’t worry, with the right specialist help and a little bit of understanding, you will be more than capable of getting things right. If you can’t find any of these documents, then approach the ISM directly and ask them for some guidance and input. Even if they are not available at this point, there is a simple exercise that you can complete to help you review your project and identify whether security is something you will need to consider.

Consider your project with the following aspects in mind:

  • Business – what would the impact be on your business – in terms of both profit and reputation – if the system, application or solution you are implementing was successfully attacked? Think about this in the following terms…….
  • Confidentiality – does the project contain any sensitive data? If that were to get into the public domain or into the hands of a malicious attacker, what would that mean to your company’s reputation and yours as a Project Manager within your organisation? Does it contain data you may have a requirement to protect, for example, personal information or credit card data?
  • Integrity – what if a malicious attacker were to alter the data or information in the system? What if you had a website advertising property for sale and someone altered the price or photos? What damage would this cause to the organisation?
  • Availability – if your system were unavailable to users, what impact would that have on the business? Assess this in terms of time periods – an hour might not cause major issues but if your system was down for a day or longer, that could potentially have a huge impact on your organisation.

Don’t worry if you can’t work out the precise pounds and pence at this point. If you think the company could be badly affected, the ISM will definitely want to chat to you. Once you have this information, go to your ISM and assess the risks together. Consider whether the organisation is willing to accept them or whether security needs to be factored into your project. In many cases, they will be able to provide you with some advice and guidance about what you can do.

It is likely that you will need to do some form of security testing against your system, in order to be confident that it is secure. The remainder of this article is focused on demystifying this, helping you to make this process work well for your project, and assisting you in reducing delays on potential additional costs.

Common Terminology

There is some common language that you may come across, which has been broken down into non-technical language, in order to assist you in knowing what is being asked of you, where to get it and what you need to do.

Terminology What is it? What it means to you Potential impact
Scoping An exercise to determine the scope of any security testing that needs to be done on your project. Passing information to a security partner, such as a URL of the application you are working on.
If it’s not built, yet discuss the design documentation and any relevant network diagrams.
If you have a good security partner, they can advise you at this stage. Don’t try and get them just to give you a tick in the box when it comes to security. That just stores up pain for the future.
Ensuring you get the scope right in the first place reduces the risk of scope change during project delivery.
Scope change invariably means more money, time and effort.
Penetration testing This is the activity of testing an application, network or any other product you have security concerns about. It should not be confused with Performance or UAT testing.
It has a specific focus on checking for security risks and should be a manual process providing you with recommendations on how to reduce your risks.
Penetration testing is a term that can have many meanings to different people. It generally refers to people testing the security of your system.
Provide information to a security partner so that they can assess the risks involved.
Provide any information requested prior to the start of any testing. 
Ensure your security partner can get access to what they need (see Security Requirements, White Listing, Credentials and 3rd parties below).
Should no penetration testing be completed, you cannot be confident that your system is secure.
Vulnerabilities Vulnerabilities are, in simple terms, flaws or bugs in your system that have security implications. 
They are generally ranked according to the size of the risk they impose on your system. 
Review the report with your Information Security Manager and technical team to assess whether you need to fix the vulnerability or accept the risk it presents to the company.
This could potentially add time to your project whilst you fix or accept these vulnerabilities.
3rd parties (inc. Hosting Company) On occasion organisations use external hosting companies to store web-based applications. If you are having a product tested, that is hosted by a 3rd party, your security partner will need their permission to proceed.
If this is left, it can cause delays to a project. Identify early on if there is a ‘change period’ for getting approval and if so get it as early as possible. 
Your security partner should not proceed with any assessments until this is received.
If there is a delay in getting approval from 3rd parties, it could prove quite expensive in Cancellation Fees.
Test requirements These are provided before a security assessment begins by your security partner. They should detail all that they need from you to ensure successful security assessments. Get started on them as soon as you receive the requirements. Too often projects are delayed due to lead times that were not identified early.
If you don’t understand, then ask for specific details on what is required. 
If you have a large project to run with several stakeholders, a conference call with all parties involved is a good way to ensure everyone knows what they must do.
If the test requirements are not ready on time, then you run the risk of a delayed/cancelled start, which means additional time, effort and cost.
Credentials Login details for a product that you require scoping/testing. Credentials can be provided with a URLto assist in scoping a project in the initiation stages.
They will also be required for any product that requires authentication to login. 
If you have different roles, credentials for each role will be required.
Credentials are sensitive information and need to be handled correctly. 
Ensure you request these as soon as possible, because delays can mean additional time, effort and cost.
Ensure they work with your security partner before testing to avoid any additional delays.
Intrusion Detection System (White Listing) Intrusion Detection System orIDS is a piece of equipment on the network that will monitor IPs that are trying to access your network. If they are not on the ‘white list’ or ‘approved list’ then they will be denied entry. If your security partner is testing remotely (i.e. from their offices and not yours) then you will need to ensure their IP ranges have been ‘white listed’. This is normally done through a change request process. This can take up to seven working days, so ensure you get your request in early. Not having access can cause delays/cancellations to your project, leading to additional cost, time and effort.
NDA Non Disclosure Agreement Check with your legal department or ISMthat any 3rd parties you are engaging have signed an NDA. This ensures that they can’t discuss anything that they are privy to outside of your organisation or their own. If any 3rd parties are not under NDA, they can (should they wish to) share sensitive information about your system.
Remediation This is a period after security testing where vulnerabilities can be fixed Too many project managers don’t leave enough time to complete remediation before going live. Ensure there is enough time for this to be completed and verified as having been done successfully by your security partner. Additional time, cost and effort
Delays to your go-live date
Going live with a system that is not secure

What to do with your report

Once you have completed testing, you will receive a report. As a minimum, we would expect the report to have the following information in it:

  • Vulnerabilities rated by the severity of their threat to the security of your system. This information will be communicated with your ISM to discuss what further actions you will take.
  • Executive summary: this is written to provide an overview of the state of the security of your system. It is a good way to share the results of the report with Project Boards and Project Stakeholders.
  • Detailed descriptions of the vulnerabilities: this is the information that your technical team will need in order to re-create the vulnerabilities that were found.
  • Recommendations: this section is written to offer advice to the technical team on how to fix vulnerabilities that were found in the system. When it comes to remediation, this section will be very important to your technical team.

Reviewing your security report can be intimidating, and thoughts of major delays and increased costs will more than likely cross your mind. Try to keep a level head until you are completely clear on your organisation’s position on what will need remediating and what risk will be accepted. If you are using a 3rd party developer, they can be obstructive when a security partner ‘picks holes’ in their system. Reassure them that all members of the project are trying to achieve the same thing – a secure product that is fit for purpose.

Once you have had time to review the details with your ISM and your technical team, agree what the next steps will be in terms of the remediation of any vulnerability, and arrange for your security partner to complete a verification of the fixes, to confirm that they have been resolved.

All too often, information about vulnerabilities and their remediation stays with each project. This can cause successive projects within an organisation to experience the same recurring vulnerabilities. Our recommendation would be to feedback to the relevant managers in your development teams what was found, and how it was resolved, in order to reduce the chances of it happening in the future. Eventually, you would hope to see an overall reduction in vulnerabilities in your projects.

Conclusion

Information security is not as intimidating as it may seem, but it is a vital consideration for any responsible Project Manager. With a proactive approach, any potential threat to budget or schedule from the extra burden of information security management can be mitigated early in the project and managed smoothly throughout.

The key to information security is to gather as much information together as you can as early in the project as is feasible, to communicate openly with your Information Security Manager, to keep a level head when vulnerabilities are revealed, to work to remediate them, and to ensure that each remediation is verified.

Organisations should also try and learn from experience. If information about vulnerabilities and their successful remediation is fed back to the Information Security Manager, this can be passed to the development function in order to ensure that improvements are being made with each successive project.

Strategically, it would also be prudent to check that information security is being considered at a Project Board level, so that it can be built into business plans from the word go.

 

 

Accreditations

As members of CHECK we are measured against high standards set by CESG for the services we provide to Her Majesty's Government.
We are certified in the ISO 9001 quality management system (QMS) in the UK, ensuring reliable delivery of our products and services.
We are certified to comply with ISO 14001 in the UK, an internationally accepted standard that outlines how to put an effective environmental management system in place.
MWR is certified to comply with ISO 27001 to help ensure our client information is managed securely.
As an Approved Scanning Vendor MWR are approved by PCI SSC to conduct external vulnerability scanning services to PCI DSS Requirement 11.2.2.
We are members of the Council of Registered Ethical Security Testers (CREST), an organisation serving the needs of the information security sector.
MWR is a supplier to the Crown Commercial Service (CCS), which provides commercial and procurement services to the UK public sector.
MWR is a Qualified Security Assessor, meaning we have been qualified by PCI to validate other organisation's adherence to PCI DSS.