10 security principles forintegrated operations

Point of View by Paul Carr

Energy, Utilities & Chemicals the way we see it

2

Early estimates from the NorwegianPetroleum Directorate state that 4Q2008 total production is about 219.5million Sm3 oil equivalents (o.e.).This is 3.0 million Sm3 o.e. higherthan in the same period the yearbefore.1 Recovering and producing oiland gas has spurred technologicalinnovation and has made theNorwegian Continental Shelf (NCS)an industry-leading region inintegrated operations. OLF(Norwegian Oil Industry Association)2

coined the term ‘IntegratedOperations’ (IO) which means “real-time data onshore from offshore fieldsand new integrated work processes”.OLF has estimated the economicpotential of IO to be in the magnitudeof €34 billion. Figure 1 illustratesOLF’s plan for IO adoption forcompanies operating on the NCS.

The heart of IO is the continuous flowof secure electronic informationbetween stakeholders; but that isn’talways possible for two reasons:

• security incidents are frequent• security levels vary widely.

This means that as information ispumped through the chain ofstakeholders, the risk of securitybreech is high and the result would beto break the entire supply chain.3

The classic Information Systemsdefinition of security focuses on thefollowing security services:Confidentiality, Integrity andAvailability4. For IO, the securityservices must include Authentication,Traceability, and Non-Repudiation tocover electronic partnerships. It isimportant that stakeholders can trusteach other to handle all these areas ofinformation security.

This paper lists 10 important securityprinciples to consider when designingor implementing IO related processesor systems to enable companies toexchange information in a trusted andsecure environment.

1 http://www.npd.no/English/Aktuelt/Pressemeldinger/2009/2009_1_9_prodtall_nov_08.htm 2009 Press release on estimates for yearly production.2 Oljeindustriens Landsforening; http://olf.no3 Source: Capgemini’s Point of View on Transformation of Process Control Security in the Energy Industry4 Ref: ISO 7498-2

Figure 1: OLF’s plan for IO adoption for companies operating on the NCS

Time2010 20152005

Generation 1• Integrated onshore and offshore centers•Continuous onshore support

Integration across onshore and offshore

Traditional processes•Self-sustainable fields•Specialized onshore units•Periodic onshore support

Limited integration

Generation 2• Integrated operation centers

of operators and vendors

•Heavily automated processes•24/7 operation

Integration across companies

Potential

Source: Oljeindustriens Landsforening (OLF)

2. Define clear boundaries ofresponsibilityIn IO, many stakeholders may handlethe same data. To be able to agree onhow to secure the data, it is necessaryto define clear boundaries ofresponsibility on when and wheredata is handed over between differentparties. This means defining securitydomains. A security domain is an areawhere information is handled with thesame level of security. Suppose anoperator creates a domain called“Operator drilling control domain”where all information is related todrilling operations and owned by theoperator. The operator then setscertain levels of security that must bemaintained within this domain. Forexample, one security level coulddictate that the availability of servicesshould be 99.8% at all times.

There may be many security domainswithin one company, depending onrequirements. Stakeholders shouldhave their own security domains.Figure 2 shows a security domainconsisting of the systems andinfrastructure needed for a businessfunction. Typically a company couldhave a security domain for eachbusiness function and one for each

1. Agree baseline securitymeasures between stakeholdersFor companies to work together it iscritical that all involved parties handleshared information in a securemanner and can trust the availabilityof services. This means that all partiesmust acknowledge an agreed level ofbase security. For further reading, ISOIEC 17799 / 27002 provides excellentexamples of base security scenarios.The OLF document: “104 -Information Security BaselineRequirements for Process Control,Safety, and Support ICT Systems”demonstrates this concept in IO. Themost important part of thesedocuments is the requirement to havea security policy showing the intentand direction for information security,and the requirement to perform riskassessments for the systems used. TheOLF Information Security BaselineRequirements (ISBR) tool is availableto check compliance against theirstandard.

Another alternative is to use theAmerican Petroleum Institute“Security Guidelines for the PetroleumIndustry”, which is morecomprehensive but covers the wholeindustry.

3. Establish contractsExternal contractsContracts must be establishedbetween security domains (internaland external) to define required levelsof security within each domain.Chapter 6.2.3 of ISO/IEC 27002 is acomprehensive list of what to includein contracts between two parties:

a) the information security policy;b) controls to ensure asset protection,

including procedures and physicalprotection;

c/d) training and awareness inmethods, procedures, and security;

e) provision for the transfer ofpersonnel

f) responsibilities regarding hardwareand software installation andmaintenance;

g) a clear reporting structure andagreed reporting formats;

h) a clear and specified process ofchange management;

i) access control policy;j) arrangements for reporting,

notification, and investigation ofinformation security incidents

k) a description of the product orservice to be provided, and adescription of the information tobe made available along with itssecurity classification;

l) the target level of service andunacceptable levels of service;

m) the definition of verifiableperformance criteria, theirmonitoring and reporting;

n) the right to monitor, and revoke,any activity related to theorganization’s assets;

o) the right to audit;p) an escalation process for problem

resolution;q) service continuity requirements;r) the respective liabilities of the

parties to the agreement;s) responsibilities with respect to

legal matters and how it is ensuredthat the legal requirements aremet, e.g. data protectionlegislation;

t) intellectual property rights andcopyright assignment and protection

geographical area. As a minimum adrilling rig should have its ownsecurity domain.

It is particularly important to definethe boundaries between securitydomains. A physical boundary may beeasy to define (e.g. at the connectionbetween a router and a cable), but itmay also be necessary to define logicalboundaries. Physical networks andequipment may be shared, so theboundary when exchanging data maybe between logical VPN connections.Note however that it is still importantto define who has responsibility forthe shared equipment – this stillbelongs to a physical security domain!

Figure 3 shows an example logicaldomain where the physicalboundaries are not the main issue, butrather the several logical networks areset up as part of one physicalnetwork. Typically on a drilling rigwith high cost communications tocentral locations you may share thephysical link between severalstakeholders who have their ownseparate logical domains.

Companies often need informationthat is stored on the intranets of theirpartners, suppliers or customers. SOIL(Secure Oil Information Link) is afully managed, members only networkhub that enables companies to costeffectively share and exchangeinformation with guaranteed speed,reliability and security, over a NorthSea wide network.5

The SOIL network Hub is a goodexample of a security domain with clearboundaries at the firewalls connectingSOIL to the companies using it.

Note that the boundaries of domainsneed to have some security controls,usually handled by a router orfirewall. It should however not benecessary to set up two firewalls nextto each other, one for each domain, ifyou can trust the party responsible forthe other domain.

Energy, Utilities & Chemicals the way we see it

10 security principles for integrated operations 3From Policy to Implementation: The Status of Europe’s Smart Metering Market 3

Figure 2: Physical domain consisting ofservers, systems, and network segments

Source: Capgemini

of any collaborative work;u) involvement of the third party

with subcontractors, and thesecurity controls thesesubcontractors need to implement;

v) conditions forrenegotiation/termination ofagreements.

Internal contractsThe above list is fairly comprehensiveand is a good basis for a contractbetween two parties. For internalcontracts, either between domains orbetween services inside the domains aless detailed list may be used. Thecontracts (or level of trust) may simplycontain defined levels of Confidentiality,Integrity and Availability, e.g. for eachConfidentiality level definingrequirements for logical access(passwords, encryption), for Integritylevel validation checks, and forAvailability levels % uptime per month.

4. Ensure all data has clearownershipThis is a very important baserequirement that is often notconsidered. Without ownership thereis nobody to describe the securityrequirements and the securityimplementation is purely based onguesswork by the peopleimplementing the solutions. Theowner not only defines the security

5 The SOIL Network was first introduced in Norway in 1998, and quickly became an established communication tool. The network has since expanded to Aberdeen and is now available asa North Sea wide network. Today, the network boasts over 215 companies as registered users, and has expanded to include a wide range of collaboration services.http://www.oilcamp.com/portal/ProductsServices/SOILNetwork/tabid/63/Default.aspx

4

requirements, but is also responsiblefor classifying the data according tosecurity policies. This means, at aminimum, to decide the level ofconfidentiality required for that data.

Every piece of data must have anowner who is responsible for definingwhat security is required. Usually thiscan be done at a high level, e.g.ownership could be for allmaintenance data, all personnelrelated data and so on. Sometimes,however, ownership may have to be ata lower level, e.g. different ownershipof the various data that is contained inthe lifecycle history of some drillingequipment (the equipment ownerwants to know what forces it has beeninfluenced by, the operator wants toknow the exact coordinates it hasbeen at during drilling).

The ownership of data may alsochange in time, e.g. RFID (radiofrequency identification) data mayhave one owner when being capturedas a piece of cargo is scanned duringtransport, and another owner whenhandled in a logistics or maintenancesystem.

The important point, however, is thatat all times all data has a clear ownerwho decides the level of security to beused, where the data is held orwhatever security domain it travelsthrough. All parties involved mustagree who the owner of the data is atany time.

5. Trust authentication done bysourceAs people or systems access data orsystems across security domains, it isimportant that one can trust that theperson or system is what or who itclaims to be. This is particularlyimportant for access into othercompanies’ domains. An examplewould be an expert at a subcontractoronshore needing direct access to asystem offshore. If a contract or trustrelationship has been set up betweenthe two companies (or their security

domains), then one company shouldbe able to trust the authenticationsystem at the other company: If thatcompany says he is John Smith, thenthis company will also believe that,and he should not have toauthenticate a second time.

This is the basis for federated identitysystems, and should be used ifpossible. The alternative would be re-authenticating whenever passingbetween security domains, a virtuallyunmanageable task when frequentlycrossing domains, which is the case inIO. Federated identity systems arebecoming increasingly used exactlyfor that reason – an example is themore than 80 products that havepassed the Liberty6 alliance testing asfederated identity solutions.

Note that even if a user isauthenticated at an external sourceyou may still choose to set upseparate security mechanisms to limitthe access for such users, e.g. use aDemilitarized Zone (DMZ)7 providingremote access control to specificsystems/applications (according totime limitations in approved workpermits).

6. Ensure activity loggingDuring a real-time activity, likedrilling or production, it isparticularly important to log all

Figure 3: Logical domain showing VPN connections for a service/system

Source: Capgemini

activities as they happen, to make itpossible to analyze what happenedafter an incident. This allows learningfrom mistakes (or learning from whatwas done well). It may be used to findout what went wrong so it may becorrected, or it may be to detectsecurity incidents. Also, it may beimpossible to react fast enough tohandle the event in real-time, butusing the log of what happened allowsproper correction before furtherdamage is done. The log itself shouldcontain information about whathappened, who (or which system) wasresponsible, when it happened, andwhat system it affected. The level ofdetail for the logging may be setaccording to what is practical anduseful. The logging is normally bestperformed by the applicationsthemselves – this needs to be specifiedas part of the requirement for a newapplication.

Analysis of the log can be partlyautomated if required, even withautomatic action to correct theproblem (e.g. using IntrusionPrevention Systems). It is, however,important to decide when and howlogs should be analyzed, andimplement that decision. The decisionon what to analyze should be basedon a risk assessment. Logs that are notused are purely a resource drain.

6 See: http://www.projectliberty.org/ - this is an organization that has established standards to ensure that federated identity solutions can work together.7 DMZ = Demilitarized Zone, meaning a separate domain that can be accessed from outside and is protected separately.

Energy, Utilities & Chemicals the way we see it

10 security principles for integrated operations 5

You also may need to share loginformation to integrate monitoringacross the borders of the organization– proper analysis may not be possiblewithout access to all data. Note,however, the need to safeguard thelogs for forensic and incidentinvestigations.

There is no such thing as 100%security, so logging what happens isan additional safeguard to handleevents that shouldn’t have happenedin the first place.

7. Establish multilayerprotectionDue to the fact that it is impossible toachieve 100% protection, it is wise toprotect at multiple layers. Ideally anyitem should only need to be protectedat source – e.g. a database or datastore should maintain its ownprotection (in practice this wouldnormally mean encrypting the data).Knowing that this is never enough,one should also protect the systemaccessing the database, the computerrunning that system, the securitydomain that contains that system, theborders of the company network, andthe borders of the industry network(e.g. the SOIL network).

These layers of security will make itmore difficult for hackers (crackers)or viruses (or any malware) to causeharm, without making it unnecessarilydifficult to perform normaloperations.

8. Be openSecurity by obscurity does not work.This has been shown in practice manytimes – the safest systems are oftenthose written as open source, whereanybody can inspect the code andpoint out or correct security flaws.

More importantly – use openstandards and open securitymechanisms, e.g. PKI basedencryption where the basic algorithmis well known but still unbroken, theTSL communication protocol, an IETF

standard, or the lower level IPseccommunications standard.

Also: there are many security toolsthat rely on contributions provided inthe open community – these are oftentools that lead the way in the realm ofIT security and can be used to ensurethe security of your systems.

The Jericho forum describes how toimplement the deperimeterizationconcept and gives some ideas how itcan be done in a standard and openway8. They have also defined“Commandments” similar to the 10security principles in this paper but tobe used in general situations ofdeperimeterization.

9. Use role- and asset-basedaccessHistorically access control has beenstraight forward by setting up user Xto allow access to asset Y. When youhave many users and many assets, andthe users keep changing their roles(e.g. often offshore users may havemany roles) this gets very difficult tomaintain, and even more difficult tocheck if it is correct.

The current best practice for accesscontrol in the oil industry is role andasset based access control. This meansthat for each overall asset (an overallasset being for instance an oil field orplatform), several roles are defined.The access required to perform thefunctions for that role is then defined,e.g. a driller needs access to drillingsystems, and a maintenance engineerneeds access to maintenance systems.

A new user (or system) is then givenaccess to the systems or assets that isrequired for the role(s) performed,and as roles are changed or added, theaccess is changed accordingly – youonly need to know what roles areperformed – not the details of accessrequired, these have already beendefined as part of the role definition.Figure 4 shows how users, roles andassets may be linked together.

Ideally this access system could beextended to context based accesswhere the situation the user is in isconsidered, e.g. if the user is accessingsystems from a laptop during travel(rather than in the secure workenvironment) he should not get thesame access.

10. Show social responsibilityAs in any situation where you interactwith other parties, it is important tofollow some simple rules for theinteraction to work well:

• Don’t be the one infecting the otherparties with virus or spam. Ensuringbase security as explained earlierwill help, but also make sure thatfirewalls and routers are set up tostop unwanted traffic both ways –not just inbound traffic.

• Do not spam or overload the otherparties with unnecessary traffic.Send the data that is necessary forthe work in hand, and only that. Itis easier and more efficient toremove unneeded data at the sourcethan later.

• Ensure that when an incident occursyou can work together acrossorganizational boundaries to solvethe issue.

A security policy should be producedand used as a basis to raise awarenessof information security and of the riskassociated with information exchange.

Figure 4: Role and asset based access

RoleAsset User

Source: Capgemini

8 See http://www.opengroup.org/jericho/ for details

6

Today in the Oil and Gas Industrythere are some companies that havemade a lot of progress in addressingthese principles internally. Howevermany companies are lacking in mostareas. Once several stakeholders areincluded the total solution willnormally have very weak security thatit which will take a long time and alot of effort to correct unless it isconsidered up-front. This weaksecurity may even be a showstopperfor an important collaboration processbetween stakeholders and thereforeprevent major savings being made (refthe €34 billion savings estimated onthe Norwegian Continental Shelf asmentioned at the beginning of thispaper).

Note that IO is about integration of asupply chain across several domains,possibly across several stakeholders. Itis also important to manage the bigpicture, and ensure that the wholeinformation flow functions accordingto the intended purpose. This bigpicture covers the integration part ofIO, and is not covered here – it is allabout proper architecture, andmanaging the orchestration ofinformation as it flows betweensystems and people.

As Thore Langeland, ManagerIntegrated Operations at OLF says:

“Information Security is very much aboutattitude and behavior in the daily work.So the last security principle in thisdocument - show social responsibility - isone of the more important principles. Forthis reason OLF has made somemnemonics for the individual in abrochure available on OLF's web site9.”

ConclusionThe 10 principles in this paper are allabout defining domains of securityand protecting those domains and theinformation within. These areimportant principles that arenecessary to protect the information,and following these principles willhelp ensuring appropriate protection.

The 10 principles are repeated here:

1. Agree baseline security measuresbetween stakeholders

2. Define clear boundaries ofresponsibility

3. Establish contracts4. Ensure all data has clear

ownership5. Trust authentication done by

source6. Ensure activity logging7. Establish multilayer protection8. Be open9. Use role- and asset-based access10. Show social responsibility.

9 http://www.olf.no/getfile.php/zKonvertert/www.olf.no/Rapporter/Dokumenter/071030%20Informasjonssikkerhet%2C%20brosjyre.pdf

Energy, Utilities & Chemicals the way we see it

10 security principles for integrated operations 7

• ISO IEC 17799 / 27002: http://www.iso.org/iso/catalogue_detail?csnumber=50297

• 104 - Information Security Baseline Requirements for Process Control, Safety, and Support ICT Systems -http://www.olf.no/101-120/104-information-security-baseline-requirements-for-process-control-safety-and-support-ict-systems-article876-1364.html

• OLF IO architecture: not published yet, but available on request

• Capgemini security services: http://www.capgemini.com/services/technology-services/security/

• Federated identity: http://en.wikipedia.org/wiki/Federated_identity

• SOIL network: http://www.rignet.com/Solutions/SOIL/The_Network/

• RFID OLF: not yet published in April 2009. See http://olf.no/

• Capgemini’s Point of View on Transformation of Process Control Security in the Energy Industry:http://www.capgemini.com/resources/thought_leadership/transformation_of_process_control_security_in_the_energy_industry/

• Jericho forum: http://www.opengroup.org/jericho/

• API - The American Petroleum Institute: http://www.api.org/policy/otherissues/

References

www.capgemini.com/energy

©2009 Capgemini. No part of this document may be modified,deleted or expanded by any process or means without prior written permission from Capgemini.

Rightshore ® is a trademark belonging to Capgemini.

SS

C-S

T20

09M

ay

Capgemini, one of theworld's foremost providers of

consulting, technology and outsourcingservices, enables its clients to transformand perform through technologies.

Capgemini provides its clients withinsights and capabilities that boost theirfreedom to achieve superior resultsthrough a unique way of working, theCollaborative Business Experience™.The Group relies on its global deliverymodel called Rightshore®, which aimsto get the right balance of the best talentfrom multiple locations, working as oneteam to create and deliver the optimumsolution for clients. Present in more than30 countries, Capgemini reported 2008

global revenues of EUR 8.7 billion andemploys over 90,000 people worldwide.

With 1.2 billion euros revenue in 2008and 12,000+ dedicated consultantsengaged in Energy, Utilities andChemicals projects across Europe, NorthAmerica and Asia Pacific, Capgemini'sEnergy, Utilities & Chemicals GlobalSector serves the business consultingand information technology needs ofmany of the world’s largest players ofthis industry.

More information about our services,offices and research is available atwww.capgemini.com/energy

About Capgemini and theCollaborative Business Experience™

For more information, please contact:

Paul Carrpaul.carr@capgemini.com

Head of Epicentre Capgemini NorgeJens Middborgjens.middborg@capgemini.com

Global Oil & Gas Centre of ExcellenceIan Mooreian.moore@capgemini.com