Conformance to legal requirements for e-Services and E-Systems

download Conformance to legal  requirements for e-Services and E-Systems

If you can't read please download the document

description

Conformance to legal requirements for e-Services and E-Systems. Luigi Logrippo Université du Québec en Outaouais University of Ottawa. Invited Talk, KCESS2012. Towards a process for producing software from legal requirements. One of the last frontiers …. Last for two reasons: - PowerPoint PPT Presentation

Transcript of Conformance to legal requirements for e-Services and E-Systems

Conformance to legal requirements

Conformance to legal requirementsfor e-Services and E-SystemsLuigi LogrippoUniversit du Qubec en OutaouaisUniversity of Ottawa

1Invited Talk, KCESS2012Towards a process for producing software from legal requirementsOne of the last frontiers Last for two reasons:In the end, IT systems must satisfy the lawThis is a difficult goalBecause of the need to bridge the long distance between legal language and IT language and implementations3

A bridge? A bridge?The lawSoftwareWhy IT isnt very good at building bridges4Humankind has been building bridges for millions of yearsBut IT is fairly new at this

Vestiges of a bridge to Sri Lanka (30Km)Reputed to be 1,700,000 yrs old FrameworkLegal requirements for e-services and e-systems exist in many areas:Tax lawsE-governanceE-commerceAccountingPrivacy protectionE-votingEnterprises have their own software in these areas:Does it comply with the law?How can new software be built to comply with the law?

5The islands and the bridges6Legal requirements for enterprise software Enterprise requirements for software Enterprise LawEnterprisePolicyEnterprise softwareextractextractlegal compliancelogical complianceimplement & verifyvalidateLegal areaSoftwarearea7Legal requirements for enterprise software Enterprise requirements for software Enterprise LawEnterprisePolicyEnterprise softwareextractextractlegal compliancelogical complianceimplement & verifyvalidateLegal areaSoftwarearea8

Legal processes9Formulating laws and policiesNormative textEstablishing legal compliance of enterprise policy to the law: These processes are entirely in the legal domain, for lawyers

Enterprise LawEnterprisePolicylegal complianceLegal area

How many research areas remain for us?10At least five

Manual activitiesAt the interface of the legal world and the IT world Extract from lawDetermine what part of the law is relevant for IT implementationExpress that part of the law in IT terminologyExtract from enterprise policyDetermine what part of the enterprise policy is relevant for IT implementationExpress that part of the policy in IT terminology

11

How are the manual activities done?12Since they are interface activities, they will require mixed teams of law experts and IT expertsIts usual for IT people to work in this manner, at the requirement extraction phase

Current practice13Legal requirements are expanded into many detailed requirementsLegal offices are used to check that these detailed requirements represent a legally defendable implementation of the lawLong checklists result from this process, and the enterprises subject to the law will use the checklists rather than the original lawChecklists usually include all sorts of things, not only software requirementsElements for requirement extraction14As always in computing, we have data structures and processesExamples of relevant data structures:Enterprise organization diagramsConcept ontologiesExamples of processes:Business processesThese exist in law, as they exist in enterprise policies, They may be difficult to findThey will be much more generic in law

Successful example: tax lawPredates computing Governments have mapped tax law into:Ontologies, essentially represented by tax formsProcesses, essentially represented by calculation rulesThere remain many areas where human intervention is necessaryInterpretationFact-findingThis is what we can expect to happen in other legal areas15

Successful example: Mesopothamian law (4000 yrs ago) One of Hammurabis almost 300 rules in Event-Condition-Action style:If anyone steals cattle or sheep, if it belongs to a god or to the court, the thief shall pay thirtyfoldEvent: Anyone steals cattle or sheep or an assCondition: If it belongs to a god or to the courtAction: The thief shall pay thirtyfold The event itself consists of three elements:Subject: AnyoneVerb: StealsObject: Cattle or sheepECA rules are very well known in ITE.g. access control rules to data

16High-level rules or RequirementsFrom the10 Commandments given to Moses:You shall not stealThis can be seen as a requirement to be translated into many ECA rules, such as the previous one Needed: an ontology to identify the types of theft that are relevant; each type can be addressed by one or more ECA-type rules

17

Creating legal ontologies18Can we put order in something like this?19Royal Bank of Canada privacy policies:We use your personal and financial information for the purposes communicated to you in your agreement(s) with us, for example to: Verify your identity; Provide you with the financial products and services requested; Communicate to you any benefit, feature and other information about products and services you have with us; Respond to any special needs or inquiries you may have; Better understand your financial situation and determine your eligibility for products and services we offer; Manage our risks and operations; Meet regulatory and legal requirements; If we have your social insurance number or social security number, we may use it for tax related purposes if you hold a product generating income and share it with the appropriate government agencies. We may also share it with credit reporting agencies as an aid to identify you. Identifying the dependencies(Ghazinour and Barker, PAIS 2011)20

Royal Bank of Canada privacy policies:We use your personal and financial information for the purposes communicated to you in your agreement(s) with us, for example to: Verify your identity; Provide you with the financial products and services requested; Communicate to you any benefit, feature and other information about products and services you have with us; Respond to any special needs or inquiries you may have; Better understand your financial situation and determine your eligibility for products and services we offer; Manage our risks and operations; Meet regulatory and legal requirements; If we have your social insurance number or social security number, we may use it for tax related purposes if you hold a product generating income and share it with the appropriate government agencies. We may also share it with credit reporting agencies as an aid to identify you. Purpose ontology lattice for RBC privacy policiesWhy a lattice(Ghazinour and Barker, PAIS 2011)21

This lattice arranges the purposes in an implication order. E.g. if one allows RBC to use personal information for mail distribution then one has also allowed them to use it for communication, marketing, and identity verification (more specific purposes)Organization structure and scenarios in the law22Sarbanes Oxley - Section.2 : Audit (3) AUDIT COMMITTEE.The term audit committee means a committee established by and amongst the board of directors of an issuer for the purpose of overseeing the accounting and financial reporting processes of the issuer and audits of the financial statements of the issuer, .

Issuer: company subject to SOXIT interpretation23Sarbanes Oxley - Section.2 : Audit (3) AUDIT COMMITTEE.The term audit committee means a committee established by and amongst the board of directors of an issuer for the purpose of overseeing the accounting and financial reporting processes of the issuer and audits of the financial statements of the issuer, .

Exercise: draw the class diagram Processes 24In law, they are usually defined only in terms of what they should achieve Examples from SOX(a) pertain to the maintenance of records that in reasonable detail accurately and fairly reflect the transactions and dispositions (b) provide reasonable assurance that transactions are recorded as necessary to permit preparation of financial statements (c) provide reasonable assurance regarding prevention or timely detection of unauthorized acquisition, use or disposition Details are found in standards, professional and best practices manualsBroken down in checklistsGeneric extraction model for enterprise governance(Hassan and Logrippo, RELAW2009)25

Concepts found in normative text are to be mapped into these classes Note specific purpose!Scanning normative text26The extraction process can be to carefully scan the law, standards, best practices, enterprise regulations, looking for elements that can be implemented in softwareConcepts found should be mapped on an extraction model that can be the basis for software implementationConceptual graphs, lattices, UMLJoint work27The resulting formalized representations are interpretations of the original textFor IT specialists, the acceptance criterion is: can this interpretation be implemented in software?For Law specialists, the criterion is: can this interpretation be defended in court?

We are interested in the intersection28

Identify and formalize the intersectionExpand it as much as possible

28Legal requirements for enterprise software Enterprise requirements for software Enterprise LawEnterprisePolicyEnterprise softwareextractextractlegal compliancelogical complianceimplement & verifyvalidateLegal areaSoftwareareaCompliance of enterprise requirements to legal requirements29

What was a legal compliance process in the legal area becomes a logical compliance check in the software areaThis can be performed by using model checkers of various kinds

Compliance of enterprise requirements to legal requirements30Proposal: A Logic-Based Process(Hassan and Logrippo)31

OK or counterexamplesChecking requirements on organization structure32Contains (Loans, PublishApplication)Contains (Loans, ReceiveFilledApp)Contains (Loans, Wapplication)Contains (Loans, JReceiveFilledApp)Contains (Loans, ConsentClient)Contains (Loans, LegalReasonException)Contains (Loans,ThankClient)Contains (Loans, DisposeData)Contains(OrderMgt, ReadApplication)Contains(OrderMgt, ValidateInfo)Contains(OrderMgt,SaveInfo)The organization must include a process to dispose of dataFormally defined Enterprise structureLegal RequirementAn organization with two main departments,incl. several processesModel checker: yes, it is included

Checking requirements on process structure33Next (ValidateInfo,SaveInfo)Next(ReadApplication, ValidateInfo)Next(Wapplication, JreceivedApp)Next(JReceivedApp,ConsentClient)Next(JReceivedApp,LegalReasonException) Next(ThankClient,DisposeData)Next(PublishApplication, ReceiveFilledApp)Next(ReceiveFilledApp,Wapplication)Next(ValidateInfo,WApplication)Next(WApplication,ReadApplication)Formally defined structureLegal requirement:Information received must later be disposedModel checker: following slide

Process non-compliance34

A path is found where information recd is savedNeed of other approachesDifferent approaches will reveal different issuesPhysicists use different methods to view material structure different methods will show different thingsE.g. the UCM-based approach proposed by Amyot et al. will lead to other discoveriesHow can we put it all togetherDo we need to put it all together?35

Implement &verify36

We are here in a familiar territory:We have compliant software requirements and we must implement them and verify the implementation Use existing software methodsBut: are the enterprise requirements that were obtained so far sufficient to derive an implementation?A lot of practical domain knowledge may still be necessaryProbably it cannot be assumed that inexperienced software developers can do thisImplement &verify37Maturity of SE methods38Unfortunately, the study of techniques to go from requirements to implementations is fairly recent and so not very mature IMOMORequirements engineering

We have been doing this for only about half a century Generic SE development method39Requirements(in natural or logic language)Specification of behavior39Specification of implementation39ImplementationMajor errors can be injected at every stepespecially between requirements and behavior specsLegal knowledge is probably still needed between steps

Validate implementation40Validate implementation41Is the resulting enterprise software compliant with the law?This must be checked since errors can be injected in the implementation processExisting software methods can be used to validate the implementation wrt legal requirements, perhaps the most practical is testingFinal testing is part of every engineering processBut, exactly what should be tested and how?The checklists mentioned are not constructed as software test suites

Certification42The end result should be certified software Certified to be conformant to the law What should the certification process be?Most probably, test suites derived from checklists Many software vendors produce software that is claimed to be compliantBut can hardly be certified

Privacy by Design43PbD is embedded into the design and architecture of IT systems and business practices It is not bolted on as an add-on Privacy becomes an essential component of the core functionality being delivered Privacy is integral to the system, without diminishing functionality(source: Information and Privacy Commissioner of Ontario, Canada)How can we build PbD in the software process?

How can we move forward?44It would help if normative text to be implemented in software was written in a different style E.g. legal text leaves much unspecifiedThe complex ontologies on which its interpretation depends are rarely specifiedThe increasing dependence on IT systems will lead legislators to include more IT language and structure in their normative styleThus facilitating the extraction processCompliance checklists will have to become more specific in terms of software requirementsMore mind-expanding ideas45Formalizing Privacy agreementsP3P and extensionsDevelopments in legal theory and practiceLegal formalization necessary to expand e-Businesse-Contracts, internationally formalizede-JudgmentsPrivacy violations to be proved automatically by using automatically obtained factual evidenceAmends to be determined automatically, on the basis of objective law

Many open areas of research46Formal semantics of normative languagesMethods to extract ontologies and processes from normative text (see RELAW workshop series)Methods to validate the result of the extraction processSuch methods will be domain-specificSoftware Engineering issues, instantiated to the legal domain Methods for validating compliance of an implementation to legal requirementsLeading to certificationThe PbD software process Conclusions47I have attempted to identify the main issues related to the problem of software compliance to legal requirements Classified the issues, by means of a proposed reference modelSome preliminary solutions and research ideas were also presented, as possible starting points