Building up a reusable security portfolio.

The quest work of security with ICT colleagues.

Looking and analyzing what the colleagues are doing, improvements and corrections getting planned (PDCA).

SIAR
S Situation
I Initiatives
A Actions
R Realisations

🔰 lost here, than.. devops sdlc.

Progress

• 2020 week:12
  
  1. Control line filled.
• 2020 week:10
  There are two story lines,
  1. What was done at reorganisations with security staff.
  2. Informations security changes, developping technology.
• 2020 week:12
  1. The SDLC floor filled with four sub topics.
  2. Added image map in the control image loops through all control pages.
  3. Technical detail pages are in the corners.

Contents

Reference	Topic	Squad
Intro	The quest work of security with ICT colleagues..	01.01
Bu line(I)	Reshufflings tasks by Reorganisations.	02.01
Bu line (II)	New tasks: security, context, ethical usage.	03.01
Initial tasks	Initial Tasks analyse & automated.	04.01
Advanced tasks	Advanced Tasks optimised & automated.	05.01
Results evaluate	Evaluating results - impact value.	06.00
	Words of thank to my former colleagues	06.02

Reshufflings tasks by Reorganisations.

Passing in time the organisation reorganises. With not that clear easily understandable actions in information processing (administration), these are possible not logically explainable. The changing level of technology does have logical changes.

Change rolling out: terminals and pc´s

Without access to computers the users had to deliver hard copy paper to a department doing the conversion (data entry).
The department OPS-DE with all their equipment was discontinued in the 80´s.
Data entry using terminals business applications done at the business lines.

Rolling out pc´s to users introduced new tasks.

• 🎭 IM-DSK A service desk for functional support, user questions.
• 🎭 OPS-OA Delivering administering the physical artefacts (hardware).
• 🎭 IM-OA Office support for helping end users in self service ICT.
• 🎭 DA-DP Meaning of information, who is authorised at what level for what.

The IM-DSK was at several reincarnations internal as long as the used technology was unique enough.
Not adding business fucntionality it was set on distance (outsourced) arround 2005
IM-OA being bound to local availablity and DA-DP strongly commited to busines are kept as internal available although the realisaton varied a lot.

Office Automation, IM-OA 💡 ICT outside ICT

The rolling out of pc´s to users in the business lines did have another effect.
Existing ICT departments were deemed not able to that support wiht new office software on the new type of machines. OPS-OA A new department was introduced. Tasks:

• Installing / defining the instructions for the Operating System.
• Installing / defining the instructions for tools, dbms, middleware.
• Support Operations planning scheduling.
• Acting as a service desk for functional questions.

These tasks are obviously duplications of ones that were already present.

Interesting issues were popping up when an integration of mulitple system is required. For example:

• A terminal emulation program can show the connection to another machine. When getting used systems at the other machine it is unusable because crashing in data processing.
  Setting default definitions for the terminal at the other side and some user instructions solved it.
• Installing a tool (eg SAS) not knowing how it is fucntioning not getting it working. Blaming the product because setup enter enter doesn´t work.
  Some tiny tweaks helped for alignment in resources.
• Having the middleware tool running (eg SAS) under a new version but unexplainable crashing in code that was previoulsy running.
  The solution was changing user profile settings that were maintained by DA-DP as those options were moved to a security tool. The memory limit confusing because what you entered was not what you get for historical reasons.

The OPS-OA department has broken up. Some is gone to others with similar taks and most has set on distance (outsources) because seen as generic, desktop service. Cooperation solving integration questions is better than ignoring those questions.

Misunderstanding ICT - business lines, shadow ICT

😲 ❌ It seems the more the technology has evolved, became more common, ...
the bigger the misunderstanding has become. Release management requirements, DR, Information Security, are becoming more problematic. The recent discussions about not understanding Machine Learning is another example.
🤔 ✅ Self service ICT, shadow ICT is often seen as succesful. The value is that it is solving business problems where standard ICT solutions are failing.

New tasks: security, context, ethical usage.

Changing the technology from an operator only to generic use by all kind of users has shifted operator tasks to users. Having many user operating machines the activities users are doing their work got requirements for better control.

DA-DP 💡, detecting - preventing abuse

Data Administration (DA) was already done, when becoming aware the need for Data Protection (DP) the most logical step have those combined in a new responsibility line. Operational activities are clear & undertstandable. It are the other tasks that are far more important in quality and certaintity.

DA-DP Tasks:

• ⚙ Authorising granting user with rights.
• 🎭 Discussing options for technical and logical requirements for data protectionand - data administration.
• 📚 Documenting archiving of the who is accountable resposible, why it was allowed and even more important why not allowed.
• ⚖ Alignment in policies by legal obligations and risk management.

There was a lot of job role uncertainty in this line. Outsourcing of work.
Distributing task over departments expecting they will do the coordination naturally with others without department concerns.
Internal policies, risk management, expected those realised by the technical staff without any alignment explanation prioritization.

Misunderstanding ICT - FCR Marketing Finance lines, shadow ICT

FCR(x) Finance Business - Marketing, sales, customer relations departments getting the freedom to do theri own ICT. Financial reporting is inside information but is sensitive at moments otheres should not know it (SOX). Marketing, sales is building op customer profiling, know your client, automated with many details combined with offloaded nomral business data. The dwh marketing siloed business line born. (90´s).
😲 ❌ The more is done without the previous central ICT organisation the bigger misunderstanding grows. Release management requirements, DR, Information Security, are becoming more & more problematic.
🤔 ✅ Self service ICT, Cloud services, shadow ICT is often seen as succesful. The value is in solving the easy business problems, although missing required policies.

A culture of everyone having their own machines

Doing all kind of ICT work on a single machine is requiring very good managed for access and resource usage. There are financial costs associated with that.

• Doing ICT by the business did look successful.
• Business lines having their own dedicated ICT staff felt belter served than having the generic ICT service.
• ICT departments found themselves that placing more isolated machines, every machine on his own is more easy (cheaper) managed.
• Having a machine on his own managed, than it is possible to outsource that.

There are a lot of financial reasons to place more and more machines.
Even the DTAP segregation for the release train, data protection and resource usage is thought to be solved by placing a machine for every "application".
😱 ❌ Just getting more and more machines got unmanageable. Machines even got placed under office desktops for critical production usage with uncontrolled external connections.
😲 ✅ Some of the ICT management questions went to managed Cloud services, others are getting known to exist by ICT staff. Tools for managing deployments getting traction.

The service bus, Service Oriënted Architecture (SOA, API´s)

In a big environment with many machines each doing some partial actions for the Business, connections are needed exchanging data, information, by message and/or bulk. MQ Message queuing and file transfers in a strict technical solutions preferable of a single external software supplier is the "servicebus".
The complexity of information versions not mentioned during the promotion of SOA, resulted in an aversion (2010). The follow up for the srvicebus is using API´s (2020).
🤔 ❓ The more is done isolated the more complexity is at required interfaces.
🤔 ✅ API´s are ideal for decoupling business processes.

Initial Tasks analysed & automated.

When terminals became common usage the question to secure processes, sdlc, and information, data, was a new one. Nothing was in place everything had to build from scratch. Even partial subsystems were build in house.

Internal & ad-hoc security, IDMS Roscoe batch

Having no personal computers, no other machines, the focus was full on the business information and the development process (begin 80´s).
⚙ Batch process run by limited operator staff
Having that limited staff to run everything controlled, security was implied.
⚙ Developers, Multi user Roscoe code editor
Securing the coding actions of developers was coded as an application verifying the commands of developers. Preventing code injection by developers was never fully reliable. Always someone found a hack.
⚙ Interactive Transactional Systems - Integrated Data Dictionary (IDD)
Having multiple IDD´s needed for the required DTAP segregations in business information and also in business logic. Used was:

• - system no 11: used as master defining other systems.
• D system no 66: Develop & module tests.
• T system no 88: integration Testing, education.
• A system no 77: Acceptance testing.
• P system no 01: real Production usage.

At test (88) non personal test accounts were used to verify build logical security would work. Securing the production processes was hard coded in business applications. Using names of accounts and the fixed names of connected terminals.
Changing authorisation needing business application changes.
😉 ✅ It worked as long it was not getting too complicated and the number of users and number of business applications not very high.
🤔 ❗ Change for a better structure more easier controllable got mentioned.

Centralisation security, removal from applications.

The first change was removing values and hard coded logic from business applications. Defining a centralised in house build call interface (api).
Commercial tools got available. ACF2 hierachical, RACF groups, LAN - AD directory
SYSYUP and DA_DP coopeating well in technical changes, adjusting and defining new naming conventions while implementing a centralised approach.
⚙ Securing system services using naming conventions (in transit)
A system service is running services, service accounts. What else would make sense.
⚙ Securing middelware tools using naming conventions (at rest)
Well secured, prohibiting not approved changes that could harm business.
⚙ Securing business logic using naming conventions (at rest)
Well secured, prohibiting not approved changes that could harm business.
⚙ Securing business logic using naming conventions (in transit)
Who is allowed to run business logic is not a 1-1 relationship. Developers testers are supposed te validate neq software as part of existing production logic.
Reusing business logic without making a local copy avoids mistakes by wrong copies and outdated versions. Making your own copy, own truth of versions is common.
⚙ Securing business data using naming conventions (at rest)
There is only one production environment but there can be muliples at other stages.
The common confusion is not seesing all these components as topics on their own that are cooperating.
😉 ✅ Centralised worked well. All discusions of many why´s felt difficult.

Building an ITOA including SoC environment

Able to do ETL processing on all IT resources including the ones related to security, build a PDB (staging) and SDDB (data marts). Using etl in the same way as a dwh for that (ITOA IT Operational Analytics), combining all resource types (90´s).

• Reusing defined cost accounting indicators in user profiles.
• Reporting what is not consistent in a system, over systems.
• Reporting what is unexpected not aligned over systems. Missing user definitions easily corrected within 24 hrs.
• Unexpected weird usage for alerts to follow up Intrusion Detection System (IDS), (IRP) Incident Response Process/Plan.

😉 ✅ Working well informing the all operational staff for ICT security quickly, the service was in control. New request able to fulfil better than human availability.
😲 ❓ After seeing information, easy interpretation, attention got lost.

Discontinuation break-up DA-DP

When merging into a bigger organisation most of tasks were relocated to other departments on far distance. Data administration moved to development. Operational user management to DEV-DBA (only DBMS tasks), local LAN acces to OPS-PB.
Granting authorisations changed into gving the same right as some ohter persons. Denying, revoking authorisations not something to bother about anymore.
In a next reorganisation used forms were noted as "the authoristion workload". Although just 20% of the time related to process those forms 100% was assumed. From that moment line management was supposed to do engineering decisions.
😲 ❓ Responsibilities change resulted in failing seeing consequences.
😱 ❌ Outsourcing, shift in responsibilities along with moving the task was initiated with promises to do it cheaper with no quality loss. Promises are broken, the request - delivery time increasing dramatically into not acceptable function (2005).

Advanced Tasks analysed not automated.

The more diverse by machines ICT got, the more new isolated initiatives were started. A consistent concept for security and asset management got lost. When delivering a new or improved ICT service the focus went to expected functionality.

Id-nrs gid-nrs, Unix - Linux LDAP

RACF Using groups is very similar to Unix where the user-id is having a primary group-id (default) and secondary groups. The technical implementation is different.
The Id-nrs (0-max) are the accounts that get something readable by an in flight translation. Groups with gid-nrs also an in flight translation.
Not used to limitations there are several surprising ones:

• a limit of 16 or 128 secondary groups associated with a users.
  No warning when failing, just some missing, debugging what went missing.
• running processes not being refreshed with new id - gid information.
  Restarting a machine might have become impossible due to unnoticed changes.
• local id-nrs gid-nrs for service processes are more reliable but confusing when different from LDAP.
• Having a subsystem spawning processes there are local id-nrs gid-nrs for service processes. More reliable but confusing when different from LDAP.

Low numbers having a special meaning. Root access (0) using ports below 1024.
💣 changes done triggered by some checklist causing a lot of trouble (2010).
😉 ✅ Working conforming internal policies, but alignment not well understood.
🤔 ❗ Change for doing it conform checklists of external suppliers got mentioned.

PAM - SSO, privileged accounts, Multi tenancy, DR

A list of technical challenges passed is a discrepancy in time.
⚙ PAM - SSO
Having security central managed is a requirement by policies. Implementing Pluggable Authentication modules (PAM) or better connecting to the delivered machine security supporting that is problematic. The issue: It is not what an application is allowed to do according to those delivering the infrastructure. Having some modules set as root (0) and suid bit (allowing switch user-id) needs to be well explained.
Single Signon (SSO) is a goal to decrease overburden users in passwordmanagement. Controlled user management is not the goal.
⚙ privileged accounts PIM
Running a solutions needing privileged accounts at the subsystem level and supporting business applications is not well accepted by those delivering the infrastructure. Privileged Identity Mangement (PIM) as first step, followed by Privileged Access Management. (PAM)
⚙ Multi tenancy - reuse solutions, tools
Using the same solution is easy on the same machine when sharing exactly the same functionality. A little variation can cause a lot of technical and other issues. Even data variations, parallel testing, can get problematic when semi-random connected.
⚙ DR, Disaster Recovery
The disaster recovery exercises showed after several tries that some data at an isolated new environment could become available. A complete operational business process not within scope. DR strategy based on a lost single central data center.
😉 ✅ Working conforming internal policies, but alignment not well understood.
🤔 ❗ Pushing changes, but not seeing internal policies as legal requirements.

Internal & ad-hoc security, Metadata IDE batch

Running solutions having their own security. Using an Integrated Development Environment (IDE). Running batch processes at operations. The delivery of information requests to an organisation having their expectations not being aligned.
⚙ Batch process run by limited operator staff
Having that limited staff to run everything controlled, security is implied. The assumption made is: no need for additional controls.
The development and testeing of flows is possible in a full sdlc life cycle but that is avoided by historical reasons.
⚙ Developers, Multi user Studio IDE tools
Using an advanced tool developers are able to access data, access information, finding hacks as part of doing their work.
Building, testing interfaces logic need to know the real information is unavoidable.
⚙ Developers, Multi user Studio IDE tools
Having multiple metadata´s needed for the required DTAP segregations in business information and also in business logic. Using:

• - Installation depot: used as master defining other systems.
• machines_D and/or separation by port nrs: Develop & module tests.
• machines_T and/or separation by port nrs: integration Testing, education.
• machines_A and/or separation by port nrs: Acceptance testing.
• machines_P and/or separation by port nrs: real Production usage.

🤔 ✅ Some thing are working fine when the instructions of external suppliers are followed. Bothersome questions are at the moment whether the customer organisation goals are met.
😲 ❓ Looking back at the situation when ICT became a commodity asset, wondering what has concptual changed (2020).

Evaluating results - impact value

Removing bottlenecks, continous flows

Integrations of object, deployment of business applications, how to align with compliancy rules at the business perspective? That is a topic that is complicated situation.
The complicated domain consists of the "known unknowns". The relationship between cause and effect requires analysis or expertise; there are a range of right answers. The framework recommends "sense–analyze–respond": assess the facts, analyze, and apply the appropriate good operating practice. (wikipedia)


It seems that it is handled as a disordered one. The common reaction is: put a tool in place , hoping the release management question will be solved by having a tool implemented.
Evaluate cases with their failures and those that had some success. A retrospective has the intention to learn from experiences. What went wrong, what good, what did we learn.

A logical framework for data management (connections)

What is missing is a framework for data connections used with localisation for the specific situation in an organisation. Some generic requirements:

• When The business environment in use is Production, managed: P<->P .
• Business applications type2. Controlled connections managed: A<->A , T<->T.
  Development is missing assuming the developer will make something up. Optionally reusing some faked test data.
• Business applications type3 are different, controlled connections managed:
  • Data retrieval: P->A , P->T , P->D in Parallel new interface: D->D
  • Data delivery: A->A , T->T , D->D
  Needing real data for data analyses but never delivering to another stage.
  New is analysing score results in an isolated location.

In a figure:

Details on what is needed more depends on the used technology.
The Test (integration/system), should look as similar as possible conform the intended production situation.
💡 Any authorisation model (security) made effective at T conform P.

Questions on how to make the development life cycle lean is removing constraints.
💡 Proposed steps in responding:

• Have data connections either simulated or active conform the Production.
• Never do dirty & quick solutions connecting data pipelines .
• Have a plan what to do first and what is to solve later.

Words of thank to my former colleagues

We had a lot fun in stressfull times working out this on the mainframe in the nineties. The uniquenes and difficulties to port it to somewhere else realising.
A few names:

• 🙏 .....

Not always unhappy by what is going on

Looking and analyzing what the colleagues are doing, improvements and corrections getting planned (PDCA).

SIAR
S Situation
I Initiatives
A Actions
R Realisations

🔰 lost here, than.. devops sdlc.