Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Software security is currently not very widely regulated directly. The following types of laws have (had) aspects in Finland that may spill over to the software security side, at least if widely interpreted:
    • Data protection (privacy) laws, most specifically the General Data Protection Regulation, but also including healthcare-specific laws, workplace specific laws
      • Must implement the necessary technical controls (but the definition of “necessary” is left for interpretation)
      • Typically, must guarantee confidentiality, integrity and availability
    • Product liability laws
      • Especially those products which have safety aspects
    • Criminal law covering intrusion into information systems
    • Security evaluation of various governmental systems
    • Secrecy of information in government and laws concerning archival
      • Requires the necessary information security controls that are based on threat analysis
      • Archives must guard against unauthorised access
    • Information security requirements for information exchanged with other countries
    • Copyright law (DRM circumvention aspects; definition of ”effective” DRM)
    • Laws on strong authentication and digital signatures
    • Finnish Constitution
      • Confidentiality of telecommunications is constitutionally protected
  • Of course, in most of these cases, there isn’t any reference to software security per se, or even to information security. Whether or not a privacy or security requirement is interpreted so that it would actually trigger software security activities is just that - interpretation. Many of these laws use language that specifically thinks security as an operational aspect.
  • Regulation and standards are usually fulfilling one or both of the following needs:
    • Internalising an externality (that is, mandating something that would not be done otherwise). This is mainly the role of government regulation, but may also be a factor in vendor management.
    • Having a ready-made set of requirements that can be referred to, so that everyone doesn’t have to reinvent the wheel. The risk here is that these lists will become ”gold standards” and meeting the requirements is what gets optimised, not security.
    • Some standards aim at keeping parties out of litigation and in a contractual world of private arbitration. These are usually security standards of closed ecosystems where the standard is a prerequisite of a membership.
    • Provide common vocabulary and concepts.
  • Regulation through legislation usually does not make specific technical requirements.
    • An exception was, for example, Germany’s digital signature legislation.
    • Usually, legislation just requires something that is ”good enough”, and interpretation is left for courts.
    • Often legal help (a lawyer) is required. However, lawyers that can effectively interpret law into engineering requirements are not common.
  • Product liability legislation may affect software security if software is a part of a physical device. It is driven by safety considerations.
    • This liability requires the product to cause damage (death, bodily injury, damage to an item or property) to consumer; and the product to be defective (in ”reasonable use”).
      • Autonomous vehicles are very interesting in this sense, and the German liability regulations for autonomous cars puts software security pretty much in the driving seat (sorry)
    • Interesting examples that can may be covered are therefore embedded systems: software in vehicles, battery charging software, software that controls actuators in consumer products, software that has a role in how much energy the device emits (radio transmitters, flashes, volume levels).
  • Some specific areas of software (again, mostly embedded software) fall under safety requirements. Often these are sectoral safety requirements, which will in turn require software security engineering.
    • Robotics, vehicles
    • Healthcare technology
      • Notably the FDA in the US has released guidance documents (2014) on the security of medical devices, when the guidance was earlier rather scarce. In the US, there are also large healthcare players (Veterans’ Affairs, as an example) who have their own software security guidance.
    • Software security activities not specifically included, mainly list technical controls and often emphasis on operational.
  • On the financial sector, PCI-DSS (Payment Card Industry Data Security Standard) has had a large impact on application security awareness.
    • In order to process credit card data (of the large card brands), PCI-DSS is a contractual requirement.
    • On the surface, mainly aims at protecting credit card information. May have positive spill-over effects on other software security aspects.
    • It is likely that the main reason is, however, to keep everyone who processes card data in a single contractually enforced system with less chance of olitigation outside the card issuers’ control sphere.
    • Specifically for payment application development, PA-DSS (Payment Application Data Security Standard) is applicable. It has quite a few of specific security feature requirements (like, on using encryption), and also has a requirement of secure and documented software development in general.
    • Compliance is measured by specifically qualified companies / people who are typically security consulting companies and consultants, called QSAs (PCI-DSS) or PA-QSAs (PA-DSS). At the time of writing in Spring 2018, there are 386 QSA companies and 62 PA-QSA companies (Payment Application Qualified Security Assessor companies). In practice, getting a QSA status has traditionally been currently a ticket to guaranteed full employment (if you like that sort of a job and don’t smell very bad).
  • The GDPR specifies that organisations could certify against a code of practice, allowing them to show compliance (and possibly get off the hook a bit easier).
    • At the time of writing, none of the codes of practice have yet a formal status. However:
      • For cloud infrastructure providers, the EU Cloud CoC and CISPE (not to be confused with CISSP) are competing
      • For software development, the European Privacy Seal (EuroPriSe) is a strong candidate that has been already in existence during the directive-based legislation
  • The most software security centric regulatory instrument in Finland appears to be VAHTI 1/2013, the application security guideline for government (”Sovelluskehityksen tietoturvaohje” in Finnish).
    • Specifies 118 requirements for application development
    • In theory, ought to become the de facto requirements document for any public sector procurement.
  • Another fairly important guideline in Finland is the National Security Audit Criteria (Kansallinen turvallisuusauditointikriteeristö, KATAKRI)
    • Applies, for example, when private companies get access to documents having national security significance.
    • Covers not only IT security but also physical security.
    • For example, has an audit question ”How has the security of executable code been ensured”. On the level III & II (”elevated” and ”high” security levels) secure software engineering principles are required from suppliers.
    • Example requirements include threat modelling, robustness testing, and static analysis.
    • Other requirements set out a fairly large number of specific controls on, e.g., use of cryptography.
  • On the EU level, a directive 2013/40/EU ”on attacks against information systems” that is in force and is being implemented nationally
    • Makes ”intentional production, sale, procurement for use, import, distribution or otherwise making available” intrusion tools illegal

...

  • Have a look at NCSC-FI (ex-CERT-FI) vulnerability coordination policy. This explains how they run the coordinated vulnerability process.
  • A 2013 study on Mozilla Foundation and Google bug bounty programs, Finifter et al.: An Empirical Study of Vulnerability Rewards Programs. This is where some of the quoted numbers in the lecture notes came from.If you can read Finnish, briefly look at VAHTI 1/2013, which is currently the only software security centric Finnish governmental guideline. (Reading the whole thing is not relevant, but just have a look at what it contains and in which way it approaches the concept.)

Additional material

  • The best book I know on the economics of information goods is Carl Shapiro and Hal R. Varian: Information Rules. If you want to read more about the effects and valuation of information assets, this is a very useful kickstart into that side of economics. It might even help you if you’re planning to start a company.
  • Jari Råman: Regulating Secure Software Development, 2006. A doctoral thesis looking at the law and economics side of software insecurity. It happens to be available from the University of Helsinki library, and if you are interested in product liability side and economics of software security, it makes interesting reading.
  • Christopher Millard: Cloud Computing Law has a good section III: Protection of personal data in the clouds. If you are interested in the problem field of cloud services and privacy, this is a fairly recent (2013) take on the subject. Note, however, that once the EU data protection regulation is passed, parts of this book can get old pretty fast.
  • Graham Greenleaf: Asian Data Privacy Laws: Trade and Human Rights Perspectives. Most privacy-related writing is about the EU and US legislation, and there is very little material available on China (and other large Asian economies). The section 7 of this book covers Chinese legislation in more detail that I’ve seen anywhere else.

...