5. Agenda
Introduction
Few words about the general
state of things
Physical concept
Review of basic and architecture things
to be done before On compliance
Statistics
Review of data types & its growing
manner
Legal
List of required documents to enable
compliance
Recommendation
List of required documents to enable
compliance
6. Security Compliance
More than software quality factors
Information Security never depends on Software quality factors
It works to get community better
McCall's quality model
Boehm quality model
Dromey's quality model
Compliance
Product operation factors
Correctness | Reliability | Efficiency | Integrity | Usability
Product revision factors
Maintainability | Flexibility | Testability
Product transition factors
Portability | Reusability | Interoperability.
7. GDPR HIPAA|HSS NIST CSF
GPDR|HIPAA|HSS|NIST CSF
Successful compliance requires deep understanding of whole system and each data chain
but not a particular modules or components
Key to Save compliance is understanding particular regulator and people that will use it
8. Software Categories
There is no software that does not belong to any particular category
or a specific domain
Clear definition and domain category relation will
make easy turn on any compliance regulator type for your software
Platform and
management
Product
manufacturing
and service
delivery
Education and
reference
Home and
entertainment
Operations and
professional
Start-ups
Content and
communications
9. Digital Chains
For the successful application of a regulator,
not enough understanding of the logic of interaction of individual
modules - it is important to understand the whole chain of use
4g/LTEInternet iotBluetooth
AWS
11. Lob application
Operation distribution and data categories
Each application category has own operational distribution
Representation 26%
(print, PDF, diagrams)
Storage 32%
(archivation)
Extraction 8%
(from archive)
Local operations 34%
(actual DB and functional algs)
DATA
LOGS SECURITY
COMPLIANCE
OPERATIONAL
12. Lob application
Data distribution
Risk probability is directly related to the volume of data
3 month
after system input
81%
13%
6%
5 year
after system input
16%
48%
6%
30%
3 year
after system input
20%
9%
30%
41%
1 year
after system input
57%
19%
21%
sensitive and insensitive data
archive (both sensitive and insensitive)
operational audit
security layer data
13. HIPAA & GDPR
Compliance software requires compliance workflows
Test DB
Test DB
Code
modification Run Tests
Code Analysis
Code Commit
Run Tests
Code
Analysis
Installer
Verification
Deploy to UAT
Manual Test
on UAT
HIPAA
Validation
Certified
Version
Build
Release
Report validation
Reportvalidation
ResetUATtodefault
AdminUIinstallationscripts
Lead Pull
request
Build
“Release”
Reset DB to init state
Reset DB
to init state
Notify
Proj. Leader
Bins | installer, ops guidelines,
validation lists
ComplianceVerification
Sign assemblies,
Generate dll lists
Build installer
Local dev env.
Remote CI dev. env. DTO
Customer Env
SVC
SSL
Pull Sources
14. HIPAA & GDPR
Project Legal Docs
White paper
EULA (End User License
Agreement)
System requirements and
functional specification
Information security
requirements
The document describing hazard / toxicity
level of the device or gadget used
16. Recommendations
Store the audit data in a separate
database, to which no one has direct
access (except for the role of the
application level) and access to
information retrieval is carried out through
double authorization.
17. Recommendations
Try not to mix sensitive and insensitive
information in one repository.
Equip digital data extraction modules with
automatic authority signing and encrypt
with a separate encryption certificate.
18. Recommendations
Have a clear and layered hierarchy of data
access and give out no more data to each
application role that is necessary for its
efficient operation with minimal and
sufficient access to sensitive data.
19. Recommendations
Do not use temporary or public folders for
any places where sensitive data is stored.
Try to save data in the folder which is
authorized only by the specific user who
launched the application.
20. Recommendations
Don`t store your data in any temporary
folders longer than its needed. While
deleting a data, use specific tools which
provide physical deletion of data, but not
just transfering it to your the trash bin.
21. Recommendations
If the application works with any sensitive
data, try to ensure that the application is
launched in the context of a user, on behalf of
another system user, who does not have an
operating system profile (the user does not
allow logging into the system) and the user`s
data context is encrypted
22. Recommendations
If the application transmits data over the
network - use data encryption during the
data transfer, provide the authorization
modules themselves with white lists of
clients and in case of emergency, the app
will be able stop the information leak
immediately.
