OCTAVE Allegro Phases

• Phase “Establish Drivers” aims to justify and prioritise the measurement criteria for risk for a specific organisation.
• Phase “Profile Assets” is designed to identify and document logical, technical, physical and people assets.
• Phase “Identify Threats” focuses on the identification of threats against the identified assets.
• Phase “Identify and Mitigate Risk” supports the valuation of the risks posed against the critical information assets. Finally, after this step, the mitigation strategy for each of the identified risks is defined.

Figure 1: OCTAVE Allegro steps and phases [2]

OCTAVE Allegro Steps

This section goes through all of the OCTAVE Allegros steps to provide an introduction into the methodology. Moreover, each step will be accompanied by a fictitious example related to AMI. Note, that dark coloured steps in figure 1 are considered major steps in order to conduct a threat analysis whereas light coloured steps are crucial when approaching a complete risk assessment.

Step 1 advises to identify all areas that impact an organisation. The methodology requires for a minimum set of areas which includes safety, health, productivity, reputation, financial and fines. For each of the impact areas, a set of criteria to measure low, medium and high impact must be developed. Table 1 provides an example for loss of revenue in case of data privacy violation. Finally, the major areas will be ranked and assigned values in order to allow for risk scoring. In case five areas have been identified and “legal penalties” is considered the top risk area, then the area would be assigned a five. An example is provided in table 6.

Table 1: OCTAVE Allegro Step 1: Establish Risk Measurement Criteria. Impact Area Example

Step 2 provides guidance in identifying critical information assets for the organisation. The methodology also provides a set of questions and asks for example for the value of assets or the dependency on assets for the day-to-day business of the organisation. Each identified information asset will be attributed additional cornerstone such as the security requirements to make up a whole information asset profile. An example for key material in a smart meter is provided in table 2. Moreover, each profile’s most important security requirement is being identified to support the later valuation of the potential impacts. OCTAVE Allegro does not provide much guidance and structure on how to identify security requirements. A way to model such requirements is by means of misuse cases [3]. The misuse case approach lends it from the unified modelling language (UML) such as used in common software engineering processes where success and fail scenarios of interaction with data and processes is being modelled. Though, the modelling of misuse cases rather focuses on the abuse of such scenarios by malicious actors (misusers).

Table 2: OCTAVE Allegro Step 2: Develop Information Asset Profile. Critical Information Asset Example

Step 3 collects information asset containers in the form of an information asset risk environment map. Information asset containers, as the name implies, can hold, process or somehow get in touch with information assets. The methodology classifies containers as technical, physical and people. Table 3 provides examples for each of the types. Correspondingly, containers are being attributed whether they are of type internal which means under control of the organisation or whether the container is external.

Table 3: OCTAVE Allegro Step 3: Identify Information Asset Containers. Container Examples

For the analysis of an organisation the type column can be attributed with minimal effort. However, for an abstract analysis such as network protocols or embedded devices, some assumptions must be made. There is no general rule on what assumptions to make.

Step 4‘s goal is to identify major areas of concern. Thereby the method foresees to consider all containers and to identify issues that could affect assets within the container. The compiled list of “areas of concern” is then expanded with the according actor, the means to realise the threat, the motive of the actor and the potential outcome. Whereby an outcome is always one out of disclosure, modification, interruption or destruction. The method documentation further lists loss next to destruction. An example, implicitly referencing the affected information asset, is provided in table 4. This step does not aim to identify a complete list of threats but helps to capture the major concerns in short time.

Table 4: OCTAVE Allegro Step 4: Identify Areas of Concern. Area of Concern Example

Note, that I have made use of this step in order to capture area of concerns for the smart meter and wireless M-Bus analysis within my master thesis.

Step 5 ensures structured identification of all potential threats. Threat trees ensure robust consideration of threats. The step relies on four trees in total. Two considering human actors with either technical or physical means and two considering technical and other problems. Part of the “Human Actors Using Technical Means” tree originating of the methodology documentation [1] is shown in figure 2.

Figure 2: OCTAVE Allegro “Human Actors Using Technical Means” Tree [1]

With each information asset, each branch of the four trees will be traversed to ensure thorough coverage and identification of threats. The guidance provides worksheets and questionnaires to simplify the activity. The result of the walk through will be a comprehensive list of threat entries as shown in table 4. Optionally, each resulting list entry can be assigned the probability of the realisation of the concerned threat scenarios with either low, medium or high likelihood.
As this is a tedious task in an assessment based on OCTAVE Allegro, I would not dig too much into it unless the previous step “Identify Areas of Concern” does not provide sufficient material or the analysis significantly lacks coverage. However, if thorough coverage is a requirement, that step cannot be circumvented.

Step 6 consists of a single activity and aims to identify the impact if a certain threat scenario becoming realised. Following that, each threat scenario will be attributed a consequence. Thus, table 4 has been expanded with an additional column to describe the consequence for each scenario. Part of table 4 and the newly added column is shown in table 5.

Table 5: OCTAVE Allegro Step 6: Identify Risks. Risk Example

Step 7 focuses on creation of a relative risk scores for each identified threat scenario. The impact on each impact area as well as the impact area importance will be reflected in the total risk score. The score should help to decide on what mitigation approach to choose in the ultimate step of the methodology. Assumed the impact area ranking in table 6 and threat scenario listed in table 5 the risk score for that specific scenario calculates as shown in table 6.

Table 6: OCTAVE Allegro Step 7: Analyse Risk. Example Risk Score Calculation

Basically, for each impact area the impact will be measured according to the criteria defined in step 1. An example of such criteria is provided in table 1. High impact will be assigned a value of three and low impact accordingly a value of one. The impact area ranking is then multiplied with the threat scenario impact value whereby the result of that calculation contributes to the total risk score.

Step 8 the ultimate step in the OCTAVE Allegro qualitative risk assessment method deals with the mitigation approach of identified risks. In general risks can be accepted, mitigated, transferred, avoided or being further monitored (deferred) whereas mitigation aims to avoid or limit the risk. However, the efforts for avoidance and limitation should never outweigh a potential impact.
Though numbers have been assigned as risk scores, their specific value only provides indication to whether a risk should to be mitigated or not. One might also take the likelihood of occurrence and some organisation specifics into account. It is suggested to divide the risks into four pools, pool one to pool four, whereby each pool groups threats for a range of the total risk score. The four pools are then approached as follows:

• Pool 1: Mitigate
• Pool 2: Mitigate or Defer
• Pool 3: Defer or Accept
• Pool 4: Accept

Depending on whether probabilities have been assigned in step 5 of the methodology it is suggested to either form a list of all risks and then split it into four pools or create a matrix which reflects the four pools and takes the probability into account. Finally, a mitigation strategy should be formulated for all risks that need to be mitigated. The mitigation strategy should list the information asset container to which the controls will be applied. Plus, the chosen strategy should consider and outline potential residual risks. An example of such a mitigation strategy is provided in table 7.

Table 7: OCTAVE Allegro Step 8: Select Mitigation Approach. Mitigation Strategy Example

Conclusion

OCTAVE Allegro is a lean risk assessment method and does not provide guidance in selecting security controls as with extensive information security management standards such as ISO 27000 [4]. However, ISO 27002 [5] and NIST SP 800-53 [6] provide a comprehensive list of controls to choose from, if needed.

References

[1] R.A. Caralli, J.F. Stevens, L.R. Young, W.R. Wilson. The OCTAVE Allegro Guidebook, v1.0. Cert Program, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213. May 2007, Online http://www.cert.org/octave/allegro.html
[2] R.A. Caralli, J.F. Stevens, L.R. Young, W.R. Wilson. Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process. CMU/SEI-2007-TR-012, CERT Program, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213. May 2007, Online http://www.cert.org/archive/pdf/07tr012.pdf
[3] G. Sindre and A.L. Opdahl. Eliciting security requirements with misuse cases. Requirements Engineering Vol. 10 No. 1, pp. 34-44. Jun. 2004 (DOI 10.1007/s00766-004-0194-4)
[4] ISO-27000:2009: Information technology – Security techniques – Information security management systems – Overview and vocabulary
[5] ISO 27002:2005: Information technology – Security techniques – Code of practice for information security management
[6] NIST. Security and Privacy Controls for Federal Information Systems and Organizations. Special Publication 800-53, Rev. 4, Final Public Draft, Feb. 2013, Online http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800_53_r4_draft_fpd.pdf

Compass Security has always been strong in web application security testing and not surprisingly, has a huge experience in identifying all kinds of web app related weaknesses, including Cross-Site Scripting. To wrap up quickly, here’s OWASP’s pretty decent definition:

“XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.”

Just in the last two months, I’ve been releasing three advisories, all related to XSS:

• CVE-2013-1413 (Synetics i-doit)
• CVE-2013-0805 (Combodo iTop)
• CVE-2013-1393 (Drupal CurvyCorners)

So why is XSS still so wide-spread? Here’s my personal top three:

1. Developers tend to care more about features than security. This might be driven by marketing or sales, time constraints or other well-founded reasons – but at the end, it doesn’t matter. Sloppy coding, not being well trained and cheap outsourcing complete this picture.
2. People suffer from the NIH syndrome (Not-Invented-Here). Instead of building their product on a well-tested code base, e.g. some common framework, they re-invent software in an insecure matter, also due to point 1.
3. People underestimate the effort of maintaining software, which is always dynamic per se. This often leads to unpatched Content-Management-Systems being used in the wild: set up once, forgotten forever.

So, what’s the solution?

Software development should always be embedded in a Secure Development Lifecycle, in order to ensure its quality in development, improvements and operation. Besides, professional software companies and communities need to treat security incidents seriously. A positive example of the three above has been the Drupal community, which has shown it’s a professional approach from day one I contacted them.

Cross-Site Scripting is so easy to fix but so powerful to exploit. However, XSS is either not treated as a concrete threat or its impact is underestimated. We can just hope that someday all web developers understand its impacts and care more about their software – and customers.

Meanwhile, we’ll stay calm and continue testing …

The subsequent sectionswill briefly introduce the major components of the AMI.

Figure 1: Advanced Metering Infrastructure Networks and Components

Head-end System
The head-end system (HES), also known as meter control system, is located within a metering company network. In most cases the metering company is the responsible DSO. The HES is directly communicating with the meters. Therefore, the HES is located in some demilitarized zone (DMZ) since services and functionality will be provided to the outside.
There is much more infrastructure at the DSO or metering company side. The collected data will be managed within a metering data management system (MDM) which also maps data to the relevant consumer. Depending on the automation level, the metering data will have influence on the DSO actions in order to balance the grid.
Exposing the HES to consumers enables some significant threats to the DSO. For example, an adversary getting hold of the HES could read all consumer data. Moreover, one could control meters or could manipulate usage data or generate alerts in order to disturb the DSO operations or at least trigger the computer incident response team (CIRT) and maybe force the DSO to backup to some business continuity plan (BCP) while analysing and recovering the HES.

Collector
The collector, also known as concentrator or gateway serves as communication node for the HES. Depending on the infrastructure the collector could be a meter itself. Its primary function is to interface between the HES and the meters and/or other collectors within its neighbourhood – the neighbourhood area network (NAN).
Not only the head-end but also the collector exposes threats. The collector is physically exposed to adversaries. Moreover, it has a trust binding to the HES and the NAN side and is thus privileged to communicate with either end. Adversaries might exploit the fact in order to attack the HES. Additionally, on the NAN side, adversaries might impersonate the collector to setup a man-in-the-middle scenario or to invoke arbitrary commands at the meters.

Meter
The meter is installed at consumer premises. When integrated with a collector, it directly communicates to the HES. As a meter it either communicates with the collector or may serve as a relay in order to route packets between nearby meters and the collector. Some meters provide an interface for appliances. With retail consumer that network is known as the home area network (HAN). Meters do also provide local diagnostic ports for manual readout, installation and maintenance tasks as shown in figure 2.
From an attackers perspective the meter is the entry point to building automation, DER and usage data. But the meter is also a relevant part of the smart grid and under no circumstances should its manipulation allow critical influence or affect the availability of the grid or parts of it.

Communication
The infrastructure consist of several networks of which all could rely on absolutely different media and a multitude of protocols. In total, three networks are commonly described when referring to the AMI. The WAN, NAN and HAN.

Wide Area Network
The WAN does connect a meter or collector to the HES. The WAN is sometimes also referred to as the backhaul network. Communication on the WAN link is mostly Internet protocol (IP) based and does commonly rely on standard information technology (IT) media and technology stacks such as fibre optic cables (FOC), digital subscriber line (DSL), general packet radio service (GPRS), multi-protocol label switching (MPLS), power line carrier (PLC) or some sort of private network. A brief overview on PLC for WAN side communication is provided in [1]
The CEN/CENELEC/ ETSI Smart Meter Co-ordination Group (SMCG) does not identify a specific protocol but proposes to rely on “secure and non proprietary protocols and communication platforms” [2] for bulk transmission from collectors that bundle a large number of meters.

Neighbourhood Area Network
The NAN connects meters and collectors. Typical NAN devices are electricity, gas, water or heat meters. organisations sometimes refer to the NAN as local metrological network (LMS) [3], field area network (FAN) [4] or the metering LAN [5].
Although standards such as the IEEE 802.15.4 [6], [7] based ZigBee profiles are gaining momentum, the industry and regulators seam to struggle on a common standard. Utilities among the European union nations seem to prefer the meter bus standard for NAN communication [3] although the ENISA does not list [4] the meter bus as a NAN protocol.

Home Area Network
Depending on the consumer type the HAN could also be named as building area network (BAN) or industrial area network (IAN). Whatever its name is, the purpose of the HAN is to integrate additional gas, water or heat meters. The HAN could allow for intelligent building automation and does also allow the integration of DERs with the smart grid.

Figure 2: Home Area Network and Local Bus Blueprint

To optimize consumption during peak hours a utility might for example decide not to entirely turn off but to throttle large heating, ventilation, and air conditioning (HVAC) appliances to balance the grid. For that purpose, consumers will be required to grant utilities or a third-party supplier access to their appliances. However, intelligent control does not necessarily require the intervention of an external part. Thus, an intelligent HVAC might decide to throttle automatically based on the real-time pricing information provided by the utility.
Meters in the US largely focus on ZigBee for HAN communication [8]. Profiles for home automation and smart energy are specified in [9], [10]. The Europe based open metering system (OMS) group is pushing a specification that relies on M‑Bus whereby the wireless M‑Bus stack is compatible with the KNX specifications [11]. KNX is very popular in home automation.

Local Bus
Common interfaces for diagnostic purposes are provided as two or three-wire serial lines, current loop or as an optical interface [12], [13].

References
[1] M. Rafiei and S. M. Eftekhari, A practical smart metering using combination of power line communication (PLC) and WiFi protocols, In Proceedings of 17th Conference on Electrical Power Distribution Networks (EPDC), 2012, pp. 1–5, May 2012
[2] Smart Meters Co-Ordination Group. Standardization mandate to CEN, CENELEC and ETSI in the field of measuring instruments for the development of an open architecture for utility meters involving communication protocols enabling interoperability M/441: Final Report v0.7. Dec. 2009
[3] Federal Office for Information Security (BSI) Germany. Technische Richtlinie BSI-TR-03109-1: Anforderungen an die Interoperabilität der Kommunikationseinheit eines intelligenten Messsystems, v0.5. 2012
[4] ENISA. Smart Grid Security: Annex I. General Concepts and Dependencies with ICT. 2012
[5] EN 13575-1:2002: Communication system for meters and remote reading of meters – Part 1: Data exchange
[6] IEEE Std 802.15.4:2011. IEEE Standard for Local and metropolitan area networks – Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
[7] C. Bennet and D. Highfill. Networking AMI Smart Meters. In Proceedings of Energy 2030 Conference, 2008. ENERGY 2008. IEEE. pp 1-8. Nov. 2008 (DOI 10.1109/ENERGY.2008.4781067)
[8] V. Aravinthan, V. Namboodiri, S. Sunku and W. Jewell. Wireless AMI Application and Security for Controlled Home Area Networks. In Proceedings of Power and Energy Society General Meeting, 2011 IEEE. pp. 1-8. Jul. 2011 (DOI 10.1109/PES.2011.6038996)
[9] ZigBee Alliance. Home Automation Public Application Profile. ZigBee Profile: 0×0104 Revision 26, Version 1.1, Feb. 2010
[10] ZigBee Alliance. Smart Energy Profile Specification. ZigBee Profile: 0×0109, Revision 16, Version 1.1, Mar. 2011
[11] EN50090-4-1:2004. Home and Building Electronic Systems (HBES) Part 4-1: Media independent layers – Application layer for HBES Class 1
[12] EN 13575-6:2008: Communication system for meters and remote reading of meters – Part 6: Local Bus
[13] EN 62056-21:2002, Electricity metering – Data exchange for meter reading, tariff and load control – Part 21: Direct local data exchange

Purpose of Smart Meters
The reason for smart meters is to enable the operators to improve their infrastructure towards a smarter grid and its six characteristics outlined. A smart meter has several advantages over a traditional mechanical meter. A smart meter does lots more [1], [2] than just providing detailed power consumption data to the operator. Primarily, a smart meter can significantly support the distribution system operator (DSO) to balance the network load and improve reliability.

Thus, a smart meter does not only lower manual reading cost but also enables to more efficiently estimate the load on the generators. It helps to more efficiently integrate distributed energy resources (DER) and helps to monitor the distribution network in order to identify power quality (PQ) issues, misrouted energy flows or fire alerts in case a consumer outage is being detected. Moreover, a meter could be used to push real-time pricing information to the consumer in order to allow appliances in the local network to optimize their power consumption according to the current rates. During an emergency, a meter could allow to disconnect consumers from the power grid. A meter could limit the consumption to a specified amount or could enforce pre-payment for defaulting consumers.

Yet, at time of writing, the effective use cases implemented heavily differ from operator to operator. Whereby all of them support at least remote meter reading. However, a security analysis should take all potential use cases into consideration since it is likely that firmware and hardware is being enhanced to support additional use cases in the near future.

Meter Reading vs. Metering Infrastructure
Typically, literature differs between advanced meter reading (AMR) and the advanced metering infrastructure (AMI) whereby AMR is to be seen as a subset of AMI [3].
AMR provides the metering company with usage data only. AMR does not allow for remote controlled action or advanced collection of power information. Thus, one-way communication from meter to the metering company is sufficient for that approach.
AMI will allow for remote initiated actions and will therefore require a two-way communication protocol. Though the border between the two approaches fades since remote initiated reading will also require for a two-way channel in AMR setups.

North American vs. European Implementations
The US as well as the European countries have developed absolutely independent implementations of the AMI. Nevertheless, the key drivers and business needs are exactly the same. Comparing the two, the preferred communication protocols in either continent are not compatible with each other.
The National Institute of Standards and Technology (NIST) and European Network and Information Security Agency (ENISA) respectively the European Committee for Standardization, the European Committee for Electrotechnical Standardization and the European Telecommunications Standards Institute (CEN/CENELEC/ETSI) mandated by the European Commission drive very similar projects to provide security guidance [4], [5] for smart grid and metering implementations. However, the guidance neither specifically requests for nor does it recommend the use of specific protocols.

References
[1] G. N. Sorebo and M. C. Echols. Smart Grid Security: An End-to-End View of Security in the New Electrical Grid. CRC Press. 2011 (ISBN 978-1-4398-5587-4)
[2] ENISA. Smart Grid Security: Annex I. General Concepts and Dependencies with ICT. 2012
[3] E.D. Knapp. Industrial Network Protocols, AMI and the Smart Grid. In Industrial Network Security: Securing Critical Infrastructure Networks for Smart Grid, SCADA, and Other Industrial Control Systems. Syngress. 2011 (ISBN 978-1-59749-645-2)
[4] NIST. Security Profile for Advanced Metering Infrastructure. v2.0, Jun. 2010
[5] ENISA. Smart Grid Security: Recommendations for Europe and Member States. Jul. 2012

Die hohe Nachfrage aus dem Raum Deutschland veranlasste die Compass Security AG, ihre Aktivitäten sowie die Kundennähe vor Ort weiter zu verstärken. Unter der Geschäftsführung von Marco Di Filippo und Walter Sprenger liegt das Kerngeschäft der deutschen Dependance nach dem Vorbild der Muttergesellschaft darin, Unternehmen im Dienste der ICT-Sicherheit rund um Präventions- und Schutzmassnahmen für deren technologische Infrastruktur zu unterstützen.

Dies ist der erste Schritt der Compass Expansions Strategie, welche durch die Erschliessung von neuen Märkten bei gleichbleibendem Service Portfolio definiert wird. Die Compass Security will weltweit an Kundennähe gewinnen und sich bei internationalen Projekten profilieren.

Kontakt Berlin
Compass Security Deutschland GmbH
Tauentzienstrasse 18
DE-10789 Berlin

Tel. +49 (0)30 2100253-0
Fax + 49 (0)30 2100253-69

www.csnc.de
team@csnc.de

Well, sometimes you may be pretty confident about your server configuration – but there are certainly occasions where you simply can’t. So, wouldn’t it be great if the user’s browser could be told to refuse unencrypted channels for a domain at all? And even remember that decision for a defined time span?
This is where HSTS comes into play. That acronym stands for “HTTP Strict Transport Security” and defines a fairly new HTTP response header that forces a user agent to solely interact with the server using HTTPS. It has been officially approved by IESG on 2nd October 2012 and is specified in RFC 6797. Let’s have a look at it:

Strict-Transport-Security: max-age=2628000

That response header causes a modern browser with HSTS support to never ever interact with the server in an unencrypted way for one month. So, in case your web application accidentally issues a non-https redirect (or anything else happens that would cause a non-https connection – e.g. a JavaScript or CSS resource loaded over http from the same domain), the user’s browser would simply use https instead. This web security policy mechanism can be enhanced by specifying the optional subdomains flag. That way, and not very surprisingly, all accordant sub domains are also put into the HSTS scope:

Strict-Transport-Security: max-age=2628000; includeSubDomains

Setting the max-age value to a month is the default recommendation, but this parameter should take the common usage pattern of your website into account. If your users connect themselves only once a month, you might want to extend the max-age period to avoid having the HSTS value expire.

Downsides? Sure.

The very initial request to a HSTS web site may still be http and thus exposed to a standard Man-In-The-Middle attack (Bootstrap MITM). In that phase, an attacker could tamper with the HSTS response header and inject invalid subdomains (DoS), disable HSTS (set max-age to 0) or poison the HSTS cache of the user agent otherwise. However, wrongly stored HSTS policies can be simply removed by clearing the local browser cache.

Another downside is rather an organizational one: once you have pushed an HSTS policy to your clients, you are no longer as free to switch back to non-https connections, of course. Their browser is configured to ignore http for the time span you have defined. Simple fix: Push a temporary policy with ‘max-age=0′ to disable it again. Also, the process of keeping your certificates valid must be properly implemented. With HSTS, there is zero tolerance for problems with respect to SSL certificates as the user is no longer able to bypass SSL warnings and “click through”.

Use it? Yes!

The advantages of HSTS clearly outweigh its downsides. It even defeats some issues it wasn’t planned for: HSTS helps in fixing mixed-content issues, defends against the cookie value being sent in plain text (in case you don’t set its ‘secure’ flag), and it may even reduce network latency by saving superfluous http-to-https redirects. Unfortunately, not all browsers support it yet, most prominently Internet Explorer. However, given HSTS was just officially approved, Microsoft will probably need to introduce it soon.

References:

• http://tools.ietf.org/html/rfc6797
• http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
• https://wiki.mozilla.org/WebAppSec/MozSecureWorld
• https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

Some electricity industry body defines the smart grid as follows: “A Smart Grid is an electricity network that can intelligently integrate the behaviour and actions of all users connected to it -generators, consumers and those that do both – in order to efficiently ensure sustainable, economic and secure electricity supply. ” [1]. The definition clearly refers to the challenging dynamics of renewable energy resources (RES) whose generation heavily relies on the fluctuate availability of sun light, wind or maybe tides. Unfortunately, it less clearly addresses changes in behavior whereby the smart grid should not only be capable to react on actions but should also directly or indirectly influence consumption behavior.

There have been six major characteristics [2, 3] identified. These characteristics describe the key benefits of a smart grid. The reference even provides additional detail on the characteristics:

It can be very tricky to analyze the relevant service account and its file system permissions in order to evaluate if a compromised ASP.NET application can access sensitive resources (file system / network / processes) on the web server. Especially from IIS 6 to IIS 7.5 there is quite a big change in how the service accounts are isolated on IIS.

Contents

Many different factors influence under which identity an IIS Worker Process runs. All the following settings need to be evaluated in order to be able make a clear statement which service account(s) are relevant.

Check IIS Application Pool Identity

1. LocalService or LocalSystem
   (Should obviously not be choosen at all, since they are high privileged built-in system accounts)
2. NetworkService
   (Built-In service account with least privileges designed for low trusted network services like a web application. It was best practice to use this account prior to IIS6 or 7. Problem is that the web application shares the process memory and file access permissions with all the other services using the NETWORK SERVICE account. This causes insufficient application isolation.)
3. ApplicationPoolIdentity
   (New and better application isolation with IIS 7.5: A “virtual” account is generated automatically with the name of the application pool, e.g. “IIS AppPool \ DefaultAppPool ” or IIS ” AppPool \ XSSViewStateUser ” and cannot be seen in the Users and Group Configuration Dialog. You need to specify exact user name in the FilePermission Dialog to give this account permission on a certain folder. Using this option, no custom service accounts need to be configured anymore for the application pools since IIS handles them automatically. This provides a maximum isolation of applications.)

Check IIS Anonymous Authentication Identity

1. IUSR
   ( Built-In account with least privileges designed to provide file system access for anonymous users of web applications. )
2. ApplicationPoolIdentity
   (The “virtual” account configured as the Application Pool Identity. –> Check IIS Application Pool Identity )

Check ASP.NET Authentication Scheme

1. <authentication mode=”Windows” /><identity impersonate=”false” />
   (With Windows authentication but without impersonation, ASP.NET will run as the Application Pool Identity and needs read and write access, depending on the application. –> Check IIS Application Pool Identity
   but as well needs the IIS-authenticated caller read access –> Check IIS Anonymous Authentication Identity)
2. <authentication mode=”Windows” /><identity impersonate=”true” />
   (With Windows authentication and impersonation, ASP.NET runs as the IIS-authenticated caller and needs read and write access, depending on the application. –> Check IIS Anonymous Authentication Identity
   but as well needs the Application Pool Identity read access –> Check IIS Application Pool Identity )
   (Attention, In IIS 7 you need to consider the fact that impersonation can only be used with the “Classic Managed Pipeline Mode” and not the “Integrated Managed Pipeline Mode” mode. Second is the default)
3. <authentication mode=”None” /> or <authentication mode=”Forms” />
   (Without Windows authentication, ASP.NET runs as the as the Application Pool Identity . –> Check IIS Application Pool Identity )

Verify Identity of the IIS Worker Process in the TaskManager

You could as well check the worker process identity in the task manager. The relevant process to check is w3wp.exe “IIS Worker Process”. This means that the User under which this process currently runs is the one which needs all the access the ASP.NET application needs. But in order to run the application it might be necessary, dependent on the settings above, that another account needs read access to the web folder as well.

Check Identity of the IIS Root Process in the Services

The relevant service to check for the IIS root process is W3SVC “World Wide Web Publishing Service“. This means that the port binding and writing the logs (W3C) is with the LOCAL SYSTEM account.

Examples

The following are the most common scenarios in the Internet area whereas no impersonation is used and Forms or None ASP.NET authentication is used.

First Scenario with Forms authentication

• IIS Application Pool Identity = NetworkService
• IIS Authentication Identity = IUSR
• ASP.NET Authentication Scheme = Forms or None

==> Result: The account NetworkService needs all the access the application needs. Whereas the IUSR does not need access at all.

Second Scenario with Forms authentication

• IIS Application Pool Identity = ApplicationPoolIdentity
• IIS Authentication Identity = IUSR or ApplicationPoolIdentity
  
• ASP.NET Authentication Scheme = Forms or None

==> Result: The account IIS AppPool \<Name of Application Pool> needs all the access the application needs. Whereas the IUSR or NetworkServicedo not need access at all.

First Scenario with Windows authentication

• IIS Application Pool Identity = NetworkService
• IIS Authentication Identity = IUSR
• ASP.NET Authentication Scheme = Windows with Impersonation

==> Result: The account IUSR needs all the access the application needs. Whereas the NetworkService does only need read access on the web application folder.

Second Scenario with Windows authentication

• IIS Application Pool Identity = NetworkService
• IIS Authentication Identity = IUSR
• ASP.NET Authentication Scheme = Windows without Impersonation

==> Result: The account NetworkService needs all the access the application needs. Whereas the IUSR does only need read access on the web application folder.

third Scenario with Windows authentication

• IIS Application Pool Identity = ApplicationPoolIdentity
• IIS Authentication Identity = IUSR
• ASP.NET Authentication Scheme = Windows without Impersonation

==> Result: The account IIS AppPool \<Name of Application Pool> needs all the access the application needs. Whereas the IUSR does only need read access on the web application folder.

fourth Scenario with Windows authentication

• IIS Application Pool Identity = ApplicationPoolIdentity
• IIS Authentication Identity = ApplicationPoolIdentity
• ASP.NET Authentication Scheme = Windows without Impersonation

==> Result: The account IIS AppPool \<Name of Application Pool> needs all the access the application needs. Whereas the IUSR does not need access at all.

Conclusion

When it comes to file system audits, you need to be aware of all the above options. However, when you deploy your own web application, it is recommended to rely on the ApplicationPoolIdentity whenever possible. This new feature has several security advantages:

• Dedicated memory space
• ACLs can be set very specifically
• No other dependencies
• …

References

• http://learn.iis.net/page.aspx/624/application-pool-identities/
• http://learn.iis.net/page.aspx/140/understanding-built-in-user-and-group-accounts-in-iis/
• http://stackoverflow.com/questions/5729264/what-are-all-the-user-accounts-for-iis-asp-net-and-how-do-they-differ
• http://msdn.microsoft.com/en-us/library/ff649337.aspx

For a starter, this article shall give a short introduction into electrical grids in general. It aims to introduce general terms and to state the difference between the former electrical grid architecture and the smart grid. Additionally, paradigm changes and challenges [1] to the current grid will be pointed-out and the conclusion will include some reasoning for a more flexible architecture – the smart grid.

Electrical grids consist of power plants that create electricity from some form of energy. They consist of towers and poles that hold wires to transport the electricity and finally make it available to the consumer. The figure provides an overview how these facilities are logically grouped into four major electric grid domains. The domain concept is not entirely new and was similarly outlined in a description of cyber security on the essential parts of the smart grid [2].

Generator domain; includes all sort of bulk power generation plants such as nuclear reactors, fossil fuel (coal or gas) plants as well as hydroelectricity plants. Typically, these are power plants that can continuously generate electricity of several hundred million watts (MW).

Transmission domain; represents the long-distance transmission network components. This includes components such as large interconnection nodes, substations and of course, cables either mounted on towers or buried underground. Electrical lines at this domain normally work on very high voltage. The voltage for that size of transmissions networks is  several hundred of thousand volts (kV). Among Europe typically values are 230kV and 400kV. Traditionally, the domain is under control of the transmission system operator (TSO). In some countries a national body or a super body of utilities operates that domain.

Distribution domain; provides the whole infrastructure to bring power to the end user (consumer). The domain also includes transformer equipment which is necessary to reduce the voltage as power is transported to the consumer. Bulk consumers typically get their power at higher voltages, for example 16kV, then common house holds for which 230 Volts and 400 Volts present common values. The domain is manged by the so-called distribution system operator (DSO).

Consumer domain; groups all sort of consumers. The industries as well as household regardless of the amount of consumption and the consumer geographic location.

The four domain model gives a good introduction into the basic concept of an electrical grid but it does by no means appreciate the full detail of the electrical grid nor does it fully model the energy flow. Due to the liberalization of the power market the generation domain is not exclusively subject to large utilities anymore. For example, consumers may want to invest into renewable energy such as photo voltaic (PV) equipment in order to cover their own power consumption and to supply current out of surplus production to others. Thus, “consumers are becoming producers or producing consumers – prosumers” [3].

Comparable changes also apply to the distribution domain. Local utilities more frequently setup own facilities to generate power which will be feed-in directly at the distribution level at high voltages. Distributed generation (DG) is nothing new to grid operators and utilities as it was already discussed in literature [4] in 2001. The referenced book [4] does also introduce several forms of generators and does recognize the technical and financial impact of distributed generation to the grid. The reader will find information on combustion turbines, PV systems, micro turbines, fuel cells, combined heat and power as well as background information on grid operations with distributed generation and storage. However, security relevant aspects are not being discussed.

Since 2001 distributed power generation significantly emerged due to renewable energy got political attention and national funding [5]. These fundings do not only focus on large installations but also take small generators in home scale into account. Meanwhile, distributed generation has taken off and demands for advances in measurement and operations of the electrical grid. Only the introduction of additional information technology (IT) will allow to coordinate all generators, storages and consumers and thus to ensure efficiency and reliability of the grid.

A functional and reliable grid is evident for a country’s stability. Therefore, governments provide guidance in form of critical infrastructure protection (CIP) programmes [6,7] and in form of written recommendations [8,9] on how to securely operate the IT stuffed new generations of grids.

References
[1] European Commission, Energy Efficiency Plan, 2011
[2] United States of America, H.R. 6582: American Energy Manufacturing Technical Corrections Act, 2012
[3] P. Hasse, Smartmeter: A technological overview of the German roll-out, 29th Chaos Communication Congress, Online http://events.ccc.de/congress/2012/Fahrplan/events/5239.en.html, 2012
[4] A. Borbely and J.F. Kreider, Distributed Generation: The Power Paradigm for the New Millenium, CRC Press, 2001, ISBN 0-8493-0074-6
[5] European Commission for Energy, Financing Renewable Energy in the European Energy Market, 2011
[6] North American Electric Reliability Corporation (NERC), http://www.nerc.com/
[7] Federal Office for Civil Protection (FOCP), The Swiss Programm on Critical Infrastructure Protection, Nov 2010, Online http://www.bevoelkerungsschutz.admin.ch/internet/bs/en/home/themen/ski. parsysrelated1.82246.downloadList.18074.DownloadFile.tmp/factsheete.pdf
[8] NIST Cyber Security Coordination Task Group, Security Profile for Advanced Metering Infrastructure, v2.0, June 2010
[9] ENISA, Smart Grid Security: Recommendations for Europe and Member States, July 2012, Online http://www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-infrastructure-and-services/smart-grids-and-smart-metering/ENISA-smart-grid-security-recommendations/at_download/fullReport

Note, this work is a preview version of an MSc Information Security dissertation in the fields of electrical grids.

Several native JavaScript functions or properties like .eval() and .innerHTML as well as several jQuery functions like .html() and .append() are considered as “unsafe”, but why? The reason is that they allow DOM manipulation using strings containing HTML code (e.g.”<b>This text is bold</b>“), which can lead to DOM Based Cross-Site Scripting vulnerabilities. To be more specific: The usage of such functions is not a problem as long as no user input is directly embedded in an “unsafe” way. jQuery can help us to safely manipulate the DOM without executing XSS in user defined inputs. But do not by mistake assume jQuery is safe per se, it only provides us some helper function to manipulate the DOM more safely.

The subsequent sections show the difference between safe and unsafe usage of JavaScript and jQuery functions in the following scenarios:

• Unsafe DOM manipulation using eval()
• Safe DOM manipulation using eval()
• Unsafe DOM manipulation using jQuery html()
• Safe DOM manipulation using jQuery html() and text()

Unsafe DOM manipulation using eval():

var txtField = "field1";
var txtUserInput = "'test@csnc.ch';alert(1);";
eval(
   "document.forms[0]." + txtField + ".value =" + txtUserInput
);

The last double quote causes the user input to be treated as JavaScript. This results in the following JavaScript code being executed by eval():

document.forms[0].field1.value = 'test@csnc.ch';alert(1);

Therefore the user input is executed:

Safe DOM manipulation using eval():

var txtField = "field1";
var txtUserInput = "'test@csnc.ch';alert(1);";
eval(
   "document.forms[0]." + txtField + ".value = txtUserInput"
);

The double quote at the end causes the user input NOT to be treated as JavaScript. This results in the following JavaScript code being executed by eval():

document.forms[0].field1.value = txtUserInput

Or in other words:

document.forms[0].field1.value = "'test@csnc.ch';alert(1);"

This results in the following HTML code:

<input type='text' id='field1' name='field1'
       value="'test@csnc.ch';alert(1);" />

Therefore the user input is not executed:

However, this snippet shows again how small the difference is between safe and unsafe usage of eval():

"document.forms[0]." + txtField + ".value =" + txtUserInput
"document.forms[0]." + txtField + ".value = txtUserInput"

Therefore it is recommended to completely ban this function from your JavaScript code.

Unsafe DOM manipulation using jQuery html():

var txtAlertMsg = "This is bold: ";
var txtUserInput = "test<script>alert(1)<\/script>";
$("#message").html(
   txtAlertMsg +"<b>" + txtUserInput + "</b>"
);

Or in other words:

$("#message").html(
   "This is bold: <b>test<script>alert(1)<\/script></b>"
);

This results in the following HTML code:

<div id='message'><b>test<script>alert(1)</script></b></div>

Therefore the user input is executed:

Safe DOM manipulation using jQuery html() and text():

var txtAlertMsg = "This is bold: ";
var txtUserInput = "test<script>alert(1)<\/script>";
$("#message").html(
   txtAlertMsg +"<b><div id='userInput'></div></b>"
);
$("#userInput").text(
   txtUserInput
);

Or in other words:

$("#userInput").text(
   "test<script>alert(1)<\/script>"
);

This results in the following HTML code:

<div id='message'>This is bold: <b>
   <div id='userInput'>test&lt;script&gt;alert(1)&lt;/script&gt;</div>
</b></div>

Therefore the user input is not executed:

Conclusion

• eval() is evil
• jQuery does not solve all your problems
• When using JavaScript or jQuery functions to manipulate your DOM you always need to know if your content may contain user input. If yes you must only use functions which encode HTML / JavaScript strings like jQuery text().

Resources

• https://www.owasp.org/index.php/DOM_Based_XSS
• https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet