Devops Meta - collection references
Securing "applications"
Patterns as operational constructs.
application security, why is it critical?
There are a lot of questions to answer:
📚 Information data is describing?
⚙ Relationships data elements?
🎭 Who is using data for what proces?
⚖ Inventory information being used ?
🔰 Somewhere in a loop of patterns ..
Most logical back reference:
previous.
Contents
| Reference | Topic | Squad |
| Intro | Patterns as operational constructs. | 01.01 |
| Secure Foundation | Why and how doing application security. | 02.01 |
| Technical app | Technical, Commercial Over The Shelf. | 03.01 |
| Business app | Business logic sources & data information. | 04.01 |
| Holistics app | Connecting Business and Technical apps. | 05.01 |
| Pattern chain | Defining the chain - Transformations. | 06.00 |
| | Dependencies other patterns | 06.02 |
Progress
- 2020 week:03
- Build new using old pages.
Much has gone to the design area, focus here on realisation details.
Duality service requests
sdlc: protecting business resources is guided by operations in the business line having their responsibilities with activities.
bianl: access to business resources is granted by business operational lines. The way of protection the copied information and new created information is a cooperative task.
The operational business line and analytics have to agree on security policies at binanl.
Why and how doing application security.
Business Information is an important core asset of the organisation.
When this goes out of control because of a data leak or unavailability (ransomware) there will be a big problem for the organisation.
Classification of applications
The word "application" is used with several contexts. Those are:
- Technical only:
- Commercial Over The Shelf (COTS) applications. ⚒ Examples are: ERP EHR software, BI ETL reporting.
- Middleware ⚒ Examples are: DBMS systems, File transfer microservices, schedulers. Also office solutions: Word, Excel connecting boxes.
- Tools ⚒ Examples: python R C java Cobol PHP & packages (libraries).
- Business (code sources & data information):
- Front end - Web services, mobile apps
- Back end In house developed
- On premise external Back end developed
The difference in DTAP concepts (Develop Test Acceptance-test Production) is part of
SDLC and
metadata design. The reverse Z is the three layered DTAP.
The difference between BI & Analytics and ERP is that BI & Analytics is expecting to do in house developing. The requirement of a connected business layer.
A COTS example approach (SAS)
These are having a lot of technical components. Middleware and tools are included and these components are not easily exchangeable but are needing to get managed.
For SAS (SAS Grid Topology) there is a figure:
More like this is at:
Grid Computing in SAS 9.4, Fifth Edition
It as a more generic approach seen with more applications also of other vendors. The component lines:
- endpoints (desktops) clients with advanced functionality
- endpoints (browser , mobile app) served by an webservice
- web applications server in a special setup for this technical system
- metadata or integrated data dictionary serving as central point for this technical system
- execution servers for running processes (eg: LSF as load balancer)
- data in any technical way of storage for the processes
Setting up security, tailoring authorisation
Defining security in the tool of the technical application is necessary but that is not able to control the data.
Only when building a vendor lock in and limiting functionality it seems doable.
For generic webservices using a generic privileged service account is a choice.
Additional disadvantages:
>- logging and monitoring complexity who has accessed what type of data
Allowing more functionality and using more strict security control is possible when authentication and authorisation is done at operating system (os) level.
Disadvantages are:
>- configuring, administrating the technical application is more work
>- more cooperation for functions with the used os support staff
Technical, Commercial Over The Shelf.
The compliancy requirement is doing logical and physical access control with a lot of attention points, BIA Business Impact Analyses.
The realisation aligning to CIA CIAA, Confidentiality Integrity Availability Auditability
Service accounts Business, Middleware, Cots
Reference to ISO27002 is made for setting up a security model. A small snapshot:
When an implementation is wanted with set least privileges everywhere for any logical function, the result will be many service accounts.
Administrators needed to switch to those service accounts in a controlled and monitored way.
Service accounts group connections - directories
The technical owner of any application resource cannot be a personal account.
It should also not run with a generic operating system master key (root).
Therefore Non Personal Accounts (NPA), service accounts, must be used.
For example:
| Function | NPA usage | Explanation |
|---|
| Installation | inst<-> |
The only one able to update that software.
NPA count=1 note: *share
|
Configuration
Tier1 master | conf<-> |
Activity after the installation.
NPA count=2 note: *share
|
Execution
| spwn<-> |
Some run time processes have the only function of starting another process with different credentials.
Logging generated for audit purposes with this service.
NPA count=3 note: *share
|
Administration
and Execution
Tier1 master | mta<-> _<DTAP> |
maintaining and running the central repository of the Cots environment (metadata).
The business DTAP environment is related. (add 4 NPA´s)
Logging generated for audit purposes with this service.
NPA count=7
|
Web Service
Tier2 | web<-> _<DTAP> |
integrating connecting webservices, running those in their own security context.
The business DTAP environment is related. (add 4 NPA´s)
Logging generated for audit purposes with this service.
NPA count=11
|
Administration
and Execution
Tier3 | adm<-> _<DTAP> |
generic business application configurations settings.
The business DTAP environment is related. (adding 4 NPA´s)
Logging generated for audit purposes with this service.
NPA count=15
|
Remarks:
- *share: This may be shared by tools in a similar risk profile.
- The tiers 1,2,3 are levels in administration risk & impact.
This not stopping here with defining NPA´s. Not covered is: Job scheduling, business usage, logging and auditing business.
The access to a technical application used by a business application is possible by a single group. Granting a technical application to business application artefact will have many group association.
Every business application has code (source) and data that is managed separately. There will by 8 accounts and 8 groups needed for each that is needing isolation.
Business logic sources & data information.
The back end in house developed applications have a structure of code development and data processing (ALC type2).
With ML, Machine Learning (ALC type3), the roles of data and source are reversed in development. Special attention when it is used.
Privileged accounts
Set up privileged accounts for the ownership and use groups for authorisation. For simplicity the privileged account and group are having the same name.
For the logic (source) there will be 4 and for the information (data) 4. For function segregation with the software life cycle and operations execution there will be loopholes in other approaches.
Granting access to users is done by adding groups to users.
Nowhere an authorisation is done on user accounts.
Logic sources code
Using the logical DTAP for code source, the following matrix is an example how to define rights on directories (folders).
Bu Logic
directory - Files |
d | t | a | p | | d | t | a | p |
|---|
| <appl group>_sd |
rwx | r-x | r-x | r-x | | rwx | r-x | r-x | r-x |
| <appl group>_st |
| r-x | r-x | r-x | | | r-x | r-x | r-x |
| <appl group>_sa |
| | r-x | r-x | | | | r-x | r-x |
| <appl group>_sp |
| | | r-x | | | | | r-x |
Remarks:
- first four-dtap columns: ACL access rights set to directories
- second four-dtap columns: ACL access rights set to files
Only at development freedom the define delete anything exists. On other levels there is a strict setting.
- As business logic is promoted and deployed/shipped with strict processes using the technical owners this is guaranteed.
- The x on directories has the meaning of able using subdirectories
The x on files that the os can execute the file. For interpreters like SAS it is not used. The developer (owner) defines those rights.
data information
Using the logical DTAP for information data, the following matrix is an example how to define rights on directories (folders).
Bu Data
directory - files |
d | t | a | p | | d | t | a | p |
|---|
| <appl group>_bd (*1) |
rwx | | | | | rw* | | | |
| <appl group>_bt (*2) |
| r-x | | | | | r-* | | |
| <appl group>_bt (*3) |
| rsx | | | | | rw* | | |
| <appl group>_bt (*4) |
| rst | | | | | r?* | | |
| <appl group>_ba (*2) |
| | r-x | | | | | r-* | |
| <appl group>_ba (*3) |
| | rsx | | | | | rw* | |
| <appl group>_ba (*4) |
| | rst | | | | | r?* | |
| <appl group>_bp (*2) |
| | | r-x | | | | | r-* |
| <appl group>_bp (*3) |
| | | rsx | | | | | rw* |
| <appl group>_bp (*4) |
| | | rst | | | | | r?* |
Remarks:
- first four-dtap columns: ACL access rights set to directories
- second four-dtap columns: ACL access rights set to files
- The owner, high privileged account is used for running regular processes creating data.
- Only at development freedom the define delete anything exists. On other levels there is a setting.
- Free for the developer using his personal and a privileged account. With this dual access he is able to develop and verify which settings are best.
- Just read only access for users accessing data.
- Users may read create &and delete any file.
- Users may read create &and any file. Deleting only when being the owner. Writing only when file permission are set accordingly.
- Business data does not be to be created by the technical owner other accounts are able to become the owner of a file.
Even personal accounts are possible to be in place. Analysts and end-user-computing are causing that.
- The x on directories has the meaning of able using subdirectories
Normal business users
Granting authorisation to user account by assigning groups is something like:
| |
_
s
d | _
s
t | _
s
a | _
s
p | _
b
d | _
b
t | _
b
a | _
b
p |
_
m
. | e
m
. | h
m
. |
x
s
d | x
s
t | x
s
a | x
s
p | x
b
d | x
b
t | x
b
a | x
b
p |
| BU Developer |
* | * | * | * | * | | | |
* | | |
* | | | | * | | | |
| BU Tester |
| * | * | * | | * | | |
* | | |
| | | | | * | | |
| BU Acpt tester |
| | * | * | | | * | |
* | | |
| | | | | | | |
| BU User Standard |
| | | * | | | | * |
* | | |
| | | | | | | |
| BU User Analyst |
| | | * | | | | * |
* | | |
| | | | | | | |
Remarks:
- The list of all middleware groups is combined it the -m. column.
- Having access to logic implies having access to run all logic (higher levels).
- The information, data, is strict segregated although with ALC type3 it might by limited production data versions.
- Switching to a high privileged account by special groups (xsd - xbp).
- The support staff at business side is a combination of other groups.
- Some combinations of groups are not allowed underpinned by "segregation of duties" conforming the business policies and risk impact analyses.
Connecting Business and Technical apps.
Securing an environment strict will cost a lot effort. Running an environment with loose security controls can cost a lot by security incidents.
Finding a balance continuous changing because incidents by attackers getting known.
DMZ and Front end - Web services, mobile apps
These kind of services are not just internally to an organisation but they are also positioned to run over the public internet.
Protecting this kind of usage is isolating the usage internal and external by different servers different machines.
An special intermediate are for this is the DeMilitarised Zone.
Changing software on managed (closed controlled) endpoints is not a sensible approach. In a secured environment auto update of desktop tools should be disabled.
A pity some desktop clie¨nts are delivered with a default auto update setting.
Servers in a secured environment should not have open access to the internet. When there are instructions for checking and doing software updates using directly the public internet, those procedures should be adjusted.
Only tested and validate software updates are allowed to get used in production environments.<
Mediated access web services.
Mediated access, analysing in an process the input for legate content, has the risk of being bypassed.
Webservice are like this figure.
Hacks examples:
-> code injection,
-> path traversal,
-> remote code execution.
When the webservice is running by a very restricted service account (least privileges) those risk can decreased or even eliminated.
User account synchronisation.
Having an central point of the technical application for dedicated access and defined users poses questions:
- How to manage defined users.
Answer: Synchronizing them with the list of OS defined users.
Same account names, same groups names (when applicable).
- How to manage the groups in the technical application environment.
Answer: Make a scriptable approach for defining groups using naming conventions.
- How to manage authorisations.
Answer: Make a scriptable approach for defining access using groups.
Have a naming convention in place.
The naming convention is usually by a hierarchical folder structure.
- Add local restricted administrator roles.
The result should be an easy understandable and easy maintainable environment that is very secure.
The high number of privileged accounts is not a problem. Well structured it is the solution.
Using OS controls implementing limited access security.
⚠ Assuming the authorisation could be done by describing them by files is a pitfall.
The files are moved and deleted at a moment in time. When the access is bound to a file it can get deleted also.
💡 using a well defined ACL (access control list) on a directory will result in a reliable reusable container in the same way of the controlled receiving of parcels.
The Unix (DAC) Solution:
- Acknowledge the need for a logical <dtap> segregation
- Define directory "business receiver" authorised by user:group <applid>_<dtap>:<applid>_<dtap>
- Define the owner of this directory: the non personal account impersonating the application (data subjects) of the receiving environment eg <applid>_<dtap>.
- Limit access to the directories to a white list of accounts (using roles - group)
- Have the execute rights on the directory set. It has not the meaning of execution but the "change directory" action.
- ❗ Have the sticky bit on the directory set.
It has no meaning for execution but for who can delete files in the directory.
- ❗ Have the Setgid bit on the directory set.
It has the meaning new created files will get that group associated with the file not the one primary group of the creator (owner).
This works even when the creator is not a member of that group.
- Access rights on the directory: world-wide open (3757 or 3746), setguid and sticky-bit
The idea is that files are registered in directories an by that will need authorisation to those directories for any access.
There are three different options of access as the owner group and others have different rights.
This is Standard solution in Unix. Commonly used at "/tmp" or Unix-mail.
It is also common knowledge fore auditors (search internet with the keywords)
Defining the chain - Transformations.
Pattern: Securing applications
Activities:
- Evaluate Technical application on behaviour & risks
- Tailor modify Technical application for better security implementations
- Define and implement tier levels for administrators
- Evaluate Business application on requirements SDLC DTAP & risks
- Tailor modify Business application for better security implementations
- Use as many service accounts as needed for achieving well isolated containers
- Monitor Log what is going on and analyse events
- Set up and test backup restore and disaster recovery processes
Remarks:
- Detailed naming and conventions are site specific.
Required other Patterns.
💡 The naming conventions pattern is complementary to the business application.
🔏 For the technical application naming conventions & procedures for the operating system must have a fit.
💡 The data exchange pattern is complementary to the business application.
Conflicting other Patterns.
This application security pattern has no conflicting other patterns.
⚠ Practical issues in realisations are having their cause in:
- Misunderstandings in the application types technical and business. Not seeing the compliancy requirements that are applicable and which of them can left out of scope.
- The connection and dependencies between business technical applications with the operating system and those of other business applications is a three layered DTAP structure.
That is not according a vision of implementing and rolling out machines and/or containers.
- Vendors dictating their own policies overruling the customers compliancy requirements.
Dependencies other patterns
This page is a pattern on securing technical and business applications.
Within the scope of metadata there are more patterns like exchanging information (data, building private metadata and securing a complete environment.
🔰 Somewhere in a loop of patterns ..
Most logical back reference:
previous.