From 9c40feff908b1cc852caba9f167b37b93b15b234 Mon Sep 17 00:00:00 2001 From: George Svarovsky Date: Wed, 26 Jan 2022 16:14:04 +0000 Subject: [PATCH] #3: Data-driven authorisation prototype thinking Refinements to design Mindmap images --- design/README.md | 6 + design/img/security design.svg | 11925 +++++++++++++++++++++++++ design/img/statute.class.svg | 38 +- design/security design.mm | 127 +- design/statute.class.puml | 9 +- design/suac.md | 2 +- prototype/README.md | 11 + prototype/img/security prototype.svg | 4971 +++++++++++ prototype/security prototype.mm | 420 + references.bib | 23 +- threats/README.md | 6 + threats/img/threat modeling.svg | 10879 ++++++++++++++++++++++ threats/threat modeling.mm | 46 +- 13 files changed, 28395 insertions(+), 68 deletions(-) create mode 100644 design/img/security design.svg create mode 100644 prototype/README.md create mode 100644 prototype/img/security prototype.svg create mode 100644 prototype/security prototype.mm create mode 100644 threats/img/threat modeling.svg diff --git a/design/README.md b/design/README.md index e66f05a..cb9bdbb 100644 --- a/design/README.md +++ b/design/README.md @@ -23,6 +23,12 @@ The approach of this phase is software engineering design and specification, pro - A description of a novel control, **symmetric unilateral access control**, is found in the [SUAC](./suac.md) document. - A design for traceability via audit logging is found in the [traceability](./traceability.md) document. +## mindmap + +(Source: `./security design.mm`) + +![security design](./img/security%20design.svg) + ## tooling notes ### PlantUML diff --git a/design/img/security design.svg b/design/img/security design.svg new file mode 100644 index 0000000..40c199d --- /dev/null +++ b/design/img/security design.svg @@ -0,0 +1,11925 @@ + + +security designBad actorsByzantineApp impersonationClock forgerytraceabilityrealisationfrom operationsaccess control by storenot offlineno APIparsing libraryrequires published message specificationvoided operations includedno native compressionallows any fusion strategyhard to correlate with statevoiding invisiblenotify voidsFinal list indexOK if intent preservede.g. insert then deleteBase graphoriginal signed operation messages(inc. constraint applys)decentralisation-agnosticpush to any storetriggerin messagingin remotesfrom updatesaccess control by storenot offlineAPIvoided operations includedno native compressionallows any fusion strategycan expose fusion utilityemitted updates ≠ signed op messagesfusion cutsconstraint applysnot decentralisedrequires a storee.g. RDBMSrequires leadercannot change leaderusing Journalno access controlse.g. read permission to partynot extensiblesupports offlineno APIcreate one!voided operations are removedcould be optionally retainedalready does compressionoverloaded strategydifferent for journal and auditno record of compression actmachine does not have identitymachine-processedstored operations ≠ signed op messagesfusionsfusion cutsalready decentralisedneed to configure 1..* 'audit master'but not to genesisaccess controlactor "party" visible to those with readactor visible to auditoraudited datacompression ok (for readability)causal orderall operations since genesisincluding voidedvisible atomic operationsidentityversions?for tracing to other systemsprincipalsused to signverification can be onlineverifiable object just receivedmust be able to sign offlinesigning secret must existmachineshow to detect malwareclone twinningholo: peers verify blockchaindo not have state for hashstart from well-known state hashrequires enough peersm-ld not a platformassociate user IDsandboxing on iOS, Androiduser responsible for malwarenativetoken from servermaybe malwareverified installno secretbrowsersession tokensame domain as JSpage server certno private key – cannot signactionsclone re-writesconstraintsfusion & fusion cut(if included in audit log)process defn and inputs must be knownapp-level procedurescf. smart contractsusersnativeuser tokenOS IDAppleIDPKIWebIDbrowseruser tokenPKIWebIDPrivacysignature verification requires identity tokenPrincipal extension point classnon-repudiableintegritywell-known state hashor more recent non-agreement state"well-known"baseline: agreement state + signed opsneed to prove a given state is consistentwith everyone else's state + some opsif no journal – how to detect forgerya recovering clone trusts one peeragreementsviewpointsCRDT: agree to start againledger: collaboration on the next blockconcurrent agreementearliest winsrequires total ordering of clocks3. leftmost ID wins2. total ticks1. cause < effectapp protocol for resolutionbut applies to manymeans is configuredrequires consensussimilar to incompatiblesplit-brainif you don't want it, lockthis is just CAPcolonies may divergeother clones may arrive at one or the otherand may transact!disjoint scope = no problemdetect: neither is caused-by the othercan arisemultiple users with authorityProof-of-Xin blockchain ≡ longest chain ruleconditionexternalconsensusFederated (Istanbul BFT)Proof-of-Xproof by duhraft / paxosleader always availableproof by asking the leaderlockingbootstrap by other"prior agreement"lock is just dataextension of authorityauthorityno consensus – quorum of oneauthority ≡ permission to triggerproof by signaturewhat if authority changesverifiable identity in dataexisting statutegenesisafter agreement, no message canbe accepted which is not caused by iton incompatible agreement opOR incompatible recoveryvoid+ replayon failure...with constraint & access checksif in fusionvoid whole fusionagreement destroys its own proximal causeslocal causal history in conflict with agreement"revup to" recovers missing opsagreement source must havemay be offline"to" is exact matchno extra in fusion"from" allows lte (as now)include proximate causesrolled-upmay still be bigU(...proximate causes, agree)on requestmay be offlinepackagedmay be biglike snapshotinserted triple may have been deleteddon't know where in a fusion a triple was deletedmay need to void tail of a fusionbreaks local integritynature of agreementcommits not sacrosanctreverse journal entryinclude did-exist flag against deleted tripleskeyed to "rid" blank nodedon't know if a deleted triple-TID existedforkthis is in the m-ld core specificationapp optionsreplace with snapshotattempt replay from journalretain forknotify appsimilar to snapshot notificationdisallow further txnslike git conflict≡ blockchain forknotify rejection to senderagreement will have arrived first (FIFO)include most recent agreement in recoveryagreement has no dataeasy to void≡ optimistic lock on data/domainsubjectchange typesDELETEINSERTdeclared in the databy propertyby property of reified tripleby queryuse @json for json-rql propertystatutesSignificant state changeTBox changeACL changeobjectall datalike a ledgersome datahow identifiedagreement applies to...speedcf. blockchainscf. not realtime txnshappen at "human speed"principle(does not require journal signatures)deliberate statute violations are ignored by correct clonesaccidental statute violationscan be revokedare unlikelyand you're not required for quorumneed to be partitioned from the agreementrules are encoded in statuteswhich change by agreementclones do not allow invalid ops according to visible rulessymmetric unilateral access control (SUAC)conflict-free constraintson merge, there could be many consequent operations to the violating stateprinciplealways violates one user's intentionmerge of a constraint change with a violationis an unviolating statepermissionsquery-based?fundamentally, what is allowed atone clone may not be at another"protest forking"should not revoke if original claim was validviolatorif not allowed, ermre-check permission (now have reason)receive protest(probably intervening messages)protester(ops caused-by violating update will enqueue)(allow app txns)stall app updatespublish "protest" messageidentifies suspect updatewith clockreceive update & check permissionanyone disagreeing can undoprotesting clone may not have permission to undo≡ constraintsame problems as constraint apply can violate local permissionswhat if bad actorpermission claim based on...datastatute"data that can be changed only by agreement"volatility hierarchyso, recipient likely to have preconditionbut not guaranteeda transaction cannot cross volatilitiesa permission claim can only bemade against less-volatile dataquery result hashuncheckable if query results have changedor during an attackbased on volatile dataeveryone has access control queriesand maintains hashesexpensiveclockbut...has causal historyuncheckable ifon another strandnot currentdata hashoperation bag hashcategoricalstate-basedclone permissions = user permissionsrequirementsno central controlmetadata is in the datadata"statutes"PermissioningACLdoes not matter if internal or externalConsensus(record of consensus is in the data)PermissionlessABoxTBoxrequirementsattacksincorrect setupapp trainingsocial engineeringapp traininginjectionapp input validationdenial-of-servicenetwork traffic analysisreplaycheck idempotency before signaturemessage service authenticationmessages signedidentify bad actorcommunication interceptionTLSsignature forgeryverified appsanti-malwarestorage tamperingrecoveryrevupcoherent but forgedwhole message with clock signedinvalid state from valid messagescannot forge signaturesincoherentSUACsnapshotSUAC (state hash)localuser OS accountmessage forgerymalwareremoteSUAClocalverified appsanti-malwareMITMmessagingidempotentnot able to signnetworkTLSidentity theftout of scope componente-invoicingauditingACLsignificant state changeslegal-docsACLconfidentialitydocument-centricfine-grained(sadly never promised)variable schemaPapersOn Mixing Eventual and Strong Consistency:Acute Cloud Typescheck referencesResearchSmart Contractsevery node executesfunction call is a txncode or code hash is on-chainPrinciplesDecentralised Extensibilityauthority modelNCSC Secure design5. Reduce the impact of compromiseMinimise cachingNo arbitrary queriesAnonymise for reportingSeparate dutiesEasy to rebuild cleanNo back doors for adminMinimise functional surfaceZone & segment network4. Make compromise detection easierMonitor for normal load, I/O, performance, transactionsMinimise access violation feedbackIndependent monitoringDetect malware C&CMonitor for normal commsLogging & events (+ integrity)3. Make Disruption DifficultPlan for failure of third partiesTest for high load (e.g. DOS)Identify bottlenecksDesign for elastic scalabilityResilience to both attack and failure2. Make Compromise DifficultEasy to do the right thingEasy management of access controlEasy maintenanceIndividually authoriseDon't do anything bespokeSeparate management from user interfacesVerify security controlsReduce attack surfaceExternal input (transform, validate or render safely)1. ContextGovernanceEnd-to-endDev/test/prod (esp. cyber-physical)Insecure networksCopies of dataNetwork-security devicesThird-party servicesDevicesRolesOperatorsDesignersShared risk propositionSuppliersThreatsAttacker capabilitiesAttack treesGoalsDefend, detect or recoverWhat risks are/not acceptableUnsafetyFraudUnavailabilityUnauthorised accessWhat is needed to operate itOther systemsPeopleConnectionsDataWhat the system is for diff --git a/design/img/statute.class.svg b/design/img/statute.class.svg index 9678dce..b7c51b3 100644 --- a/design/img/statute.class.svg +++ b/design/img/statute.class.svg @@ -1,14 +1,14 @@ -mld«extension point»StatutestatutoryClass : rdfs:Class [0..*]statutoryProperty : rdf:Property [0..*]Defines a scope of data requiring agreement.In other diagrams we'll use the «statutory»stereotype for statutory classes and properties.A class is statutory if astatutoryClass exists for it.A property is statutory ifa statutoryProperty exists.AgreementConditionstatuteStatuteStatutes and agreementconditions are themselvesstatutory.rdfsStatutestatutoryClass = rdfs:ClassstatutoryClass = rdf:PropertystatutoryProperty = rdf:typeClasses, property definitionsand the type of every subjectis statutory.accessControlStatutestatutoryClass : AccessControlstatutoryProperty : accessChoice of access controlmechanism is statutory.mld«extension point»StatutestatutoryClass : rdfs:Class [0..*]statutoryProperty : rdf:Property [0..*]statutoryUpdateVerb: 'DELETE' | 'INSERT' [1..2]Defines a scope of data requiring agreement.In other diagrams we'll use the «statutory»stereotype for statutory classes and properties.A class is statutory if astatutoryClass exists for it.A property is statutory ifa statutoryProperty exists.Is agreement required ondelete, insert or both?AgreementConditionstatuteStatuteStatutes and agreementconditions are themselvesstatutory.rdfsStatutestatutoryClass = rdfs:ClassstatutoryClass = rdf:PropertystatutoryProperty = rdf:typeClasses, property definitionsand the type of every subjectis statutory.accessControlStatutestatutoryClass = AccessControlstatutoryProperty = accessChoice of access controlmechanism is statutory.sufficientCondition*statutoryClassrdf:typestatutoryClassrdf:typerdf:typesufficientCondition*statutoryClassrdf:typestatutoryClassrdf:typerdf:type - + @@ -67,7 +67,7 @@ - + @@ -104,7 +104,7 @@ - + @@ -115,14 +115,14 @@ - + - + @@ -132,7 +132,7 @@ - + @@ -287,7 +287,7 @@ - + @@ -411,7 +411,7 @@ - + @@ -477,8 +477,8 @@ - - + + @@ -488,16 +488,14 @@ - - + + - - - + @@ -511,14 +509,79 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - @@ -545,7 +608,6 @@

- @@ -568,29 +630,40 @@ - + - + - - - - - - + + + + + + + + + + + + + + + + + diff --git a/design/statute.class.puml b/design/statute.class.puml index 9835a4a..631569f 100644 --- a/design/statute.class.puml +++ b/design/statute.class.puml @@ -12,6 +12,7 @@ package mld { class Statute <> { statutoryClass : rdfs:Class [0..*] statutoryProperty : rdf:Property [0..*] + statutoryUpdateVerb: 'DELETE' | 'INSERT' [1..2] } note bottom Defines a scope of data requiring agreement. @@ -26,6 +27,10 @@ note right of Statute::statutoryProperty A property is statutory if a statutoryProperty exists. end note +note right of Statute::statutoryUpdateVerb +Is agreement required on +delete, insert or both? +end note Statute o--> "*" AgreementCondition : sufficientCondition @@ -52,8 +57,8 @@ end note rdfsStatute --> Statute : rdf:type object accessControlStatute { - statutoryClass : AccessControl - statutoryProperty : access + statutoryClass = AccessControl + statutoryProperty = access } note top Choice of access control diff --git a/design/suac.md b/design/suac.md index fef807c..ed96ac9 100644 --- a/design/suac.md +++ b/design/suac.md @@ -134,7 +134,7 @@ Verifying authority is the same as for any other permission, as follows. For an Since access control by "whitelist" permissions may not suit all use-cases, the choice of approach is made through the `access` property of the domain itself. (Note that this requires the domain to be represented as a subject in the data; this is an open [topic of discussion](https://github.com/m-ld/m-ld-spec/discussions/75).) -Document-level _read_ permission (see [condifentiality controls](./controls.md#confidentiality)) is assigned to a principal with a single permission subject which is affirmed to exist during clone recovery. See [§protocol](#protocol) for details, including the purpose and use of the domain `secret`. +Document-level _read_ permission (see [confidentiality controls](./controls.md#confidentiality)) is assigned to a principal with a single permission subject which is affirmed to exist during clone recovery. See [§protocol](#protocol) for details, including the purpose and use of the domain `secret`. ### protocol diff --git a/prototype/README.md b/prototype/README.md new file mode 100644 index 0000000..5a8c98b --- /dev/null +++ b/prototype/README.md @@ -0,0 +1,11 @@ +# Security Prototype + +See [prototype milestone description](https://github.com/m-ld/m-ld-security-spec/issues/3). + +## milestone: Whole Domain Authorisation + +See delivered [Javascript Engine Pull Request](https://github.com/m-ld/m-ld-js/pull/85). + +## mindmap + +![security prototype](./img/security%20prototype.svg) \ No newline at end of file diff --git a/prototype/img/security prototype.svg b/prototype/img/security prototype.svg new file mode 100644 index 0000000..03be768 --- /dev/null +++ b/prototype/img/security prototype.svg @@ -0,0 +1,4971 @@ + + +security prototypeexpositionCLI PRPR descriptionextension option on startbranch -> mainSpec pre-releaserequired exports for candidate compliance testsJS engine PRw/CircleCIcompliance test"candidate" compliancelocal testextends Clonebasic docsunit testsPR descriptionlink to Spec PR(no data declaration of extension)pre-declaration of extensionbranch -> edgedata-driven authorisationmoving partsjson-rql literalshashingalso for base64Binary etc.canonicalisationor Graph Literals(discussion)Data extension installationConstraintsschemaTransport SecurityConstraint apply rejectionif reason = unauthorisedblacklist clock IDin GWC(and all forked)blacklist clone @iddoes not prevent re-joinnot in messageremove principalcan't if no permissionwith statutes, can only arise from a malicious cloneStatutes Constraintupgrades Update to AgreementvocabappliesTo: [DELETE | INSERT]Statute + AgreementConditionACL Constraintwriteable-if-patternchecks if pattern matches datawith ?s ?p ?o variables from updateO(permissions * triples)e.g. ?s a <restricted>checks insert matches patternCannot check data contexte.g. ?s <group> <restricted>e.g. ?s a <restricted>requires json-rql literalswriteable-if-class-party-roleinducable from -principaladd-only-propertycreates tombstonesesotericrequire ASKagree-if-class-principalmeans "Authority"writable-if-class-principalwritable-if-class-subject-propertye.g.subject-property = domain is-sales-orderclass = line-itemInfer statutesbecause rejection = blacklistrdf:type and subject-propertyshould be statuteschecks subject-property stateapplies-to a classAgreementsFork/Void MeldApp cbapp can export or whateverresolve, rejectokToVoid(state, agreement, updatesToVoid)process before constraintsConstraints can upgrade to agreement≪agree≫ MeldOperationExplicit agreements(must have Authority, if ACL in place)= disallow concurrentany use-cases?isolate agreement feature for testingASK queriesanalysisRequirementsstatutesCICinvoice statusschemardf:typeonly applies to deleteassumes disjoint class constraintsworkaround for missing agreement objectsbatched garbage collectevery object insert/delete is an agreementpermissionsp2pl-doccomments: by author+reviewerschema: by ownercontent: by authorsmetadata: immutableCICStateParty-rolewhole domain authorisationmoving partsinit dataPrincipal, certificate, permission[domain] Subject, access, secretACL extensionwriteN/Areadneeds access to stateread permission checkoperation encryption secret in datamld:AccessControlListextensionsmanager[Proxied] implementationsAccessControl interfacedeclaration(<[extension id]> <rdf:type> <mld:Constraint>)<[extension id]> <rdf:type> <mld:AccessControl><[extension id]> <https://nodejs.org/api/module> "[module specifier]"<[domain]> <mld:extension> <[extension id]>Pubsubcalls AccessControl extensionop encryptionsig validationcalls-back appsignapp callbacksign bufferanalysisrecovery request signatureneeds sigs before dataapp callbackjust confignegotiateTLS-likecheck readPermissionverifysignchannel secretbuffer until setdo not connect until setEncrypt operationsidentity models(with sigs)WebCryptono secure storagevia generateKey+ e.g. OIDCWebAuthnno signaturesStrong support via FIDOUses Proof-of-PossessionWebIDsimulate with PKCS8Solid can use OIDC... but then no (guarantee of) signaturesrelies on HTML keygen! diff --git a/prototype/security prototype.mm b/prototype/security prototype.mm new file mode 100644 index 0000000..159bc73 --- /dev/null +++ b/prototype/security prototype.mm @@ -0,0 +1,420 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ e.g. a seller cannot change a line item quantity, and a buyer cannot change a price +

+ + + + + + + + + + + +

+ e.g. a price cannot be updated after the 'sales order' contract point +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ problematic intersection cases: +

+

+ - Class2 disallows a property of Class1 +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/references.bib b/references.bib index c5dca9e..b848ef3 100644 --- a/references.bib +++ b/references.bib @@ -133,6 +133,16 @@ @article{hellersteinKeepingCALMWhen2019 keywords = {Computer Science - Databases,Computer Science - Distributed; Parallel; and Cluster Computing,Computer Science - Programming Languages,Computer Science - Software Engineering} } +@misc{hermanRDFGraphLiterals2010, + title = {{{RDF Graph Literals}} and {{Named Graphs}}}, + author = {Herman, Ivan}, + year = {2010}, + month = feb, + url = {https://www.w3.org/2009/07/NamedGraph.html}, + urldate = {2022-01-19}, + abstract = {This document introduces a formal semantics for (RDF) Graph Literals and Named Graphs. Graph Literals allow applications to make statements on triples (eg, provenance) without really asserting them, ie, without ensuring their existence. Named Graphs makes it possible to assign a URI to a collection of triples, and being able to make statements on the whole set (in some ways, the URI of an RDF/XML file that contains a number of triples can be considered to be a Named Graph).} +} + @misc{jagannathanAdvancedThreatModelling2012, title = {Advanced {{Threat Modelling Knowledge Session}}}, author = {Jagannathan, Venkatesh}, @@ -177,7 +187,6 @@ @article{Ma2020Writing } @phdthesis{millerRobustCompositionUnified2006, - type = {{{PhD Thesis}}}, title = {Robust {{Composition}}: Towards a {{Unified Approach}} to {{Access Control}} and {{Concurrency Control}}}, author = {Miller, Mark Samuel}, year = {2006}, @@ -267,6 +276,18 @@ @misc{raevuoriBaswarePersonalData2020 urldate = {2021-07-02} } +@misc{rixhamRDFNamedGraphs2012, + type = {Blog}, + title = {{{RDF}}: Named {{Graphs}} -vs- {{Graph Literals}} \textendash{} Webr3.Org}, + shorttitle = {{{RDF}}}, + author = {Rixham, Nathan}, + year = {2012}, + month = mar, + url = {http://webr3.org/blog/semantic-web/rdf-named-graphs-vs-graph-literals/}, + urldate = {2022-01-19}, + abstract = {An overview of Named Graphs and Graph Literals and the distinctions between them.} +} + @techreport{Sabadello:21:DI, type = {{{W3C}} Proposed Reccommendation}, title = {Decentralized Identifiers ({{DIDs}}) v1.0}, diff --git a/threats/README.md b/threats/README.md index b604f84..664a052 100644 --- a/threats/README.md +++ b/threats/README.md @@ -53,6 +53,12 @@ This section will comprise a data flow diagram composed with the [OWASP Threat D Prioritising the analysed threat vectors and relating them to the next phase of security design. +## mindmap + +(Source: `./threat modeling.mm`) + +![threat modeling](./img/threat%20modeling.svg) + --- _For bibliographic references, see the [project references file](../references.bib)._ diff --git a/threats/img/threat modeling.svg b/threats/img/threat modeling.svg new file mode 100644 index 0000000..8404069 --- /dev/null +++ b/threats/img/threat modeling.svg @@ -0,0 +1,10879 @@ + + +threat modelingDomain Threat ModelRoboticsLegal3. threatsattacksransomwarepfishingSending false messages [@lawsoc] to clients, to e.g. change bank detailssupply chain compromiseransomware<some in doc>agentsCloud providers – we do want search indexing, but want to rescind (hence private encryption key)insidersacting for defence or prosecution (or other cases) want to segregate internally ("information barriers")denial of serviceseeking 'data'<some in doc>2. application composition1. application profiledependenciesExportAuthenticationDoc Mgmt (Sharepoint)Courts (Common Platform)dataPrivacy enhancing technologies (PETs)?Disclosure could bias a caseOwnership may be unclearlawyerlaw firmclientPIIsemi-structuredcould be form-basedredline document = a new version with changesclauses(good unit for change tracking)diagramsHighly sensitiveDocument typesusersdeployment0. objectivesmanagementauthorisationOwnership may be unclear – client / firm / lawyer?authenticationauditingby clientby legal teamavailabilityintegrityconfidentialityblackout/whiteoutshreddingstandardsad-hocCASB (traffic inspection)Identify and evaluate all the cloud apps in use (Shadow IT)Enforce cloud application management policies in existing web proxies or firewallsCreate and enforce granular policies to govern handling of sensitive information, including compliance-related contentEncrypt or tokenize sensitive content to enforce privacyDetect and block unusual account behavior indicative of malicious activityIntegrate cloud visibility and controls with your existing security solutionsapproved servicesSometimes: no cloudData locality & sovereigntySmart contractsnot sure what forCommercialProse: content structuring editorLegalese: DSL for LegalJuro: machine-readable contractsHyperLawUse for barristerstag & annotation tools"structured, ordered & indexed"OCR of uploaded docscase preparationLawConnectSecurity PolicyDublin datacentreAzure Information ProtectionCan automate on keywordsWorks on MS docsdoes not require cloud storagerequires connectivity to Azure Rights Management Servicerights are enforced by appDocument encrypted with policy setLabels applied to documentsAkoma Ntoso (EU vocabulary)FIBO Legal Document (ontology class)UK Legislation SchemaCEN MetalexUsed by legislation.gov.uksources of law and references to sources of lawCourt templatesCivilCriminalCommon Platform (UK)Risk and Assurance ApproachIndustry approaches – COBIT/ITILISO Standards (27001, 27017, 27018)Cloud Security AllianceCSA STARCloud Assessments Initiative QuestionnaireCloud Controls MatrixQ&ApoliciesLaw SocietyISO27001Lexcel CertificationNCSC Cyber Essentials certificationGDPRad-hoc... but collaborationrisk-averse mentalityregulators and clients will always blame the firm (not cloud platform or software supplier)no incentive for riskshaped by client"best practices"Motivating app?incumbentsdata room / deal roomdedicated solutionsactually lag behind on featurese.g. HighQsolvable with sharepointcommon & genericsecurity managementgeneral groupwaretimesheetsbillingprogress trackingreportingdoc reposmay not be acceptable to shareee.g. "no MS""not controlled enough""end-points" are insufficiently trustedcannot control sharee securityregionsmay not allow offlinemultiple in usep2p legal doc sharingno cloud storage (necessary)courtroom has no connectivitydoes not seem to be truedocument editing & annotatione-Invoicing3. threatsdefencescheck public keys (for MIM)exploitsLaziness or unawareness of userin the app (+ app constraints)in m-ld (+ constraint implementation)attacksElevation of PrivilegeShipping company signs for delivery | | Shipping agentagentsSysadmin of MB | Skimming | Changing message signaturesThreat motivations very different if the parties use XML exclusivelyRepudiationI didn't sign that contract (or my org didn't)TamperingImpersonatingTricking the other party – agreementsEavesdroppingOthers getting a better priceBids e.g. auctionsView pricesWho is buying whatplots of land in a rowApple building datacentre in the desertBusiness Intelligencepretend to be a buyerTender spammersInvoice spammers (pay bitcoin)(Spamming of RfQs)2. application compositionThreat Dragon1. application profiledependenciesEmail systemsLink sharingBookkeeping systemsIdentity managementdataJournalcompaction"invoice" data type and access rulesDraftInvoice data typeusersSolicitorLenderNotarywitnesse.g. house buying: notary creates invoice on behalf of partySysadminShippingSellerBuyerdeploymentPersistent datam-ld on server?Traversing the public internetWeb browsersMobile devices (secured?)0. objectivesmanagementCentral registry sysadminTwo sysadmins in four-corner modelauthorisationApply data type access rulesseller/buyer algorithmspacking ratesRoles (see users)authenticationMachine strongly identifiedMost calculations are simple enough, results don't need to be in the signed dataPacking rates, e.g. multiple crates (seller/buyer algorithm)Tax rateUsers strongly identifiedauditingPurchase chains?Divergent histories can be compared (nice to have)Different histories due to concurrent/offline operations can be inspected at contract points (nice to have)All visible operations are timestamped (signed?) and attributable to user identityavailability"Common knowledge" requires read receiptsContracts (double agreement) require exchange of somethingMultiple devicesServer is offline (nice to have)Offline (client is offline)integrityContract points: request for quote (non-binding), tender (promise to give contract to winner), PO (tender to specific vendor), quoteagreement can be cumulative: "I agree with this so long as nothing changes except your agreement")State at *contract* points can be signed (both parties agree based on content; not just convergenceIs this an RfQ or a tender?Adhere to data model / disallow invalidconfidentialityFine-grained view permissions out of scopeIf have read access, nothing is confidentialinvoice and operations confidential to third partiesUsing XML as input AND outputStandardsCommercialMicrosoft Dynamics 365 Procurement and sourcingall just sending emails, no collaborationincludes Purchase Tenders (so RfQs can be sent to one or to multiple potential suppliers)BaswareSecurity Measures AnnexKissflowOAuth, SAMLFAQsISO27001:2013PCI compliant (credit cards)multiple geographiesGoogle Cloud SQLAll data encrypted at restSSL over HTTPSTradeshiftInformation Security PolicyIncident responseIntrusion detectionUpdates, security patchesCustomer security policiesSecurity audit. ... annual audit reports for the i) SOC 1 ii) SOC 2 iii) ISAE 3402 iv) ISO 27001 standards. application penetration test at least once a yearObligation of information and correction on security incidentsMalicious programs. ... necessary precautions... on the Tradeshift platform and employee workstations.Traceability. ... keep over a reasonable period of time of the logs of the actions carried out in its Platform used as part of the ServicesCEF eDelivery Building BlockSecurity ControlsRequirementsREQ6: Proof of Send/Receivelinked to timestampREQ5: Time-Referencesigned timestampREQ4: Addressee Identificationauthentication or signatureREQ3: Sender Identificationauthentication or signatureREQ2: Message ConfidentialityencryptionREQ1: Message Integritysignatures requiredPKI-based Trust Modelsonly Messaging and Transport Layernot Application Layer or Networkingfour-cornermodelParty B BackendParty B Access PointParty A Access PointParty A Backendwhy?PeppolExample BPMN workflows for BIS specifications"Peppol Access Point provider"UBL Invoiceotherwise, no versioninghas "preceding invoice" document reference (+date)PEPPOL Transport InfrastructureTechnical Overview (2011)5. Sender authentication4. Operational security requirements for serviceproviders3. Secure communication protocols2. Service providers sign an agreement beforethey join the infrastructure1. Trust is established using a Public Key Infrastructure (PKI)SOAP, WSDL, WS-SecurityPeppol Digital CertificateSecurity is PKIEN 16931nothing about securitya semantic data model of the core elements of an electronic invoiceDirective 2014/55/EUnothing about security (except as an exception for special measures)core elements of an e-InvoiceVAT breakdowninvoice totalsinvoice line item informationallowance or charge informationpayment instructionsdelivery detailscontract referenceseller' tax representation informationpayee informationbuyer informationseller informationinvoice periodprocess and invoice identifiersrequires "a European standard for the semantic data model of the core elements of an electronic invoice (the ‘European standard on electronic invoicing’)"Define e-Invoicing, meaning of collaborative, e.g. contract pointsTemplate/IncludeSections3. threats2. application composition1. application profile0. objectivesSystem-driven risk mgmtApproachlike cPP Problem DefinitionUnified Cybersecurity Ontology + OdTMOWASP Threat Modeling (STRIDE)no vulnerabilities & risk analysisapplied to hypothetical abstract p2p appScopeKey management?Not authenticationNot identityNot fine-grained confidentiality!probablyIntentions"If you had an app that addressed these concerns, would you use it?"Motivate m-ld designNo countermeasures (Design)Augment system threat modelingQuestionsX.509 centric?MethodologyOWASP Threat Modeling Workshop5. Rank ThreatsRisk assessmentOR DREADProbability * Impact (5-10-15)Accept, Mitigate, Transfer, Ignore4. Identify Vulnerabilitiesgenerate test cases (attacks)session timeoutdynamic SQLunhandled exceptionsencryptionapplied to threats3. Identify ThreatsThreat listCAPEC Domains of Attack – Softwaree.g. Injections, XSS, Replay, MITM, EavesdroppingOR Attacker = STRIDE / OCTAVEAttack Trees (CI4AM)2. Decompose ApplicationData flowsExit points (data)Entry points (targets)Trust boundaries1. Profile the ApplicationWhat security mechanismsWhat technologyWhat DataWho usingWhere deployed0. Identify ObjectivesCI4AMCIA + A'n x 2 + Auditing + MgmtDefinitionsImpactProbabilitySafeguard / CountermeasureAttack / ExploitVulnerabilty(Threat) Agent / "Subject"insidercurious attackeraccidental discoveryThreatundesired actAssettangible or notPrecursorsData Classificationavailabilitycriticalessentialsupportintegritylow/medium/highconfidentialityrestrictedconfidentialpublicsensitivity whenserialiseddeletedmodifiedcreatedSDLCFAIRLossesOntologiesEbiquity Unified-Cybersecurity-OntologyOWASP Ontology-driven threat modelling (OdTM) framework (OWL)ATT&CK knowledge base of adversary tacticsD3fend knowledge graph of countermeasures (non-RDF)STIX language for cyber threat intelligence (non-RDF)Attack LibrariesOWASP top tenCAPECalso ATT&CKCommon Attack Pattern Enum'n & Class'nAttack TreesOCTAVECVSSDREADAdds dimensionless numbers (Shostack)DiscoverabilityAffected usersExploitabilityReproducibilityDamage PotentialSTRIDEElevation of Privilegelogic flow attackauthorisation failureprocess corruptionDenial-of-ServicedefacementInformation Disclosureattacksverbose exceptioneavesdroppingvectorsfrom a data flowfrom a data storefrom a processRepudiationinsecure backuprepudiating an actionattacking the logTamperingattacksinjectionXSSvectorsvectorsmemoryfileSpoofingattacksCRSFsession hijackreplayvectorspersonmachineprocess or filePrinciplesDBMS cPP: Security Problem DefinitionAssumptionsA.CONNECTConnections to and from remote IT systems and between parts of the TSF are protectedA.SUPPORTTimestamp provision is trusted and correctA.PEER_FUNC_&_MGTTrusted external IT systems behave correctlyA.NO_GENERAL_PURPOSENo compilers or user apps on DBMS serversA.TRAINEDUSERAuthorised users are trainedA.MANAGESysadmins are not careless, willfully negligent or hostile, and follow instructionsA.AUTHUSERAuthorisation granted matches organisation policiesA.PHYSICALProtection of physical infrastructure and hardwareSecurity PoliciesP.USERAuthority only given to users trusted to act correctly and permitted by the organisationP.ROLESAdministrative authority given to trusted personnel (least privilege) with distinct role from usersP.ACCOUNTABILITYAuthorised users are held accountableThreatsT.UNAUTHORIZED_ACCESSIdentified & authenticated user gains unauthorised privilegeT.RESIDUAL_DATAUser/process acting on behalf of user gets elevated privilege "through reallocation of TOE resources from one user or process to another"T.IA_USERUnidentified or unauthenticated user gains access beyond public objectsT.ACCESS_TSFUNCManage or modify TSF bypassing protectionT.ACCESS_TSFDATAModify TSF data without being identified, authenticated or authorisedAssetsTOE resourcesUser dataTSF DataInformalVulnerabilitiesInvalid data or commandsMalware infectionsUnauthorized or unintended activityDesign flaws"Repository of high value data"GlossaryTSF: TOE Security FunctionsTOE: Target of EvaluationNCSC: System-driven risk managementDefine lossesNot the mechanismConcerned with outcomeDefine the function of the system(not a problem statement)iterate into sub-systemsverifiableachievable diff --git a/threats/threat modeling.mm b/threats/threat modeling.mm index 1776411..fe31406 100644 --- a/threats/threat modeling.mm +++ b/threats/threat modeling.mm @@ -77,7 +77,7 @@ - + @@ -183,7 +183,7 @@ - + @@ -194,12 +194,12 @@ - + - + @@ -210,16 +210,16 @@ - + - + - + @@ -347,7 +347,7 @@ - + @@ -390,11 +390,11 @@ - - + + - + @@ -414,7 +414,7 @@ - + @@ -440,7 +440,7 @@ - + @@ -474,7 +474,7 @@ - + @@ -512,7 +512,7 @@ - + @@ -524,7 +524,7 @@ - + @@ -546,7 +546,7 @@ - + @@ -561,7 +561,7 @@ - + @@ -573,7 +573,7 @@ - + @@ -581,13 +581,13 @@ - + - + @@ -754,7 +754,7 @@ - + @@ -849,7 +849,7 @@ - +