2. Authentication (authentication)

Recently, I want to talk about something, and suddenly remembered the unified identity management solution implemented two years ago. I think it has some reference significance for the increasingly strict standardization work in the industry.

The unified identity management solution discussed here mainly refers to authentication Authentication, authorization Authorization, account Account, and audit Audit.

A few years ago, when doing architecture security, I also did governance projects related to authentication/authorization control.

At that time, we were committed to overall governance of the architecture, and implemented sub-items of security control improvement by uncovering the vulnerabilities of the middle platform.

At present, due to the risk-driven supervision and regulation in various important industries, strengthening the security standardization of important systems has become an essential option.

Just like Xiao Y, who was doing special governance before, had many ideas exchanges with me, so there were also many ideas I gave during the governance process.

After obtaining authorization from the big boss of safety, he agreed to make a general comment on their case.

1. Account (account)

A reasonable account system requires robust account password policies, appropriate lifecycle, convenient permission management, and so on.

In complex situations, business parties not only have basic needs but may also need to support coexistence of platform tenants, multiple systems, and so on.

2. Authentication (authentication)

Authentication solutions not only need to consider convenience to achieve unified management of user authentication and single sign-on for information resource access.

We also need 2FA (Two-Factor Authentication) and even MFA (Multi-factor Authentication) to enhance the strength of authentication from multiple dimensions.

3. Permission (authorization)

Access control of B/S, C/S application system resources is realized through metadata resources.

It can be based on roles, groups, interfaces, data, or even more needs such as platform tenants, and the complexity of the business determines the upper limit of permission control requirements.

4. Audit (audit)

Recording and analyzing user sensitive operation logs and traffic can not only monitor risk behaviors in real time but also enable data mining through later audits to trace security incidents after the event.

II. Current Situation Analysis

After a brief discussion on the concept, let's talk about the analysis of the current situation.

1. Enumeration of non-standard systems

Friend Xiao Y's company belongs to a subsidiary of a central state-owned enterprise, hereinafter referred to as Company Y. Due to historical reasons, there are many non-standard systems that need to be dealt with urgently.

1) Purchased systems

To save R&D costs, Y Company has adopted purchased systems for many key projects, which has several pitfalls.

• High cost of maintenance expiration and transformation:

Contract maintenance also has an expiration date, and suppliers cannot deal with security rectification issues in time, making it difficult to ensure continuous and effective protection.

• No contract agreement constraint:

Although the current authentication/authorization options have already been added to the access process of the security review, many existing product commercial agreements did not have this item before.

2) Third-party systems

Y Company has some third-party cooperative systems, which are placed in their data centers by the cooperative party suppliers.

Most of the cooperative parties are state-owned enterprises/central enterprises/institutes and universities, which have no R&D iteration support but only usage support.

If it is an important system that is never moved, it is not realistic to let the supplier take the responsibility for problems, and version unification also cannot be changed.

3) Open-source systems

Some basic platforms or middleware mostly adopt open-source systems or only do secondary development. However, it is difficult to do standardized transformation for such systems without investing reliable human resources.

4) Old systems

In units with a little history, there may be some systems that cannot be transformed and cannot be taken offline in a short period of time. These systems are always a headache during security audits, but not all scenarios can go through special exception processes.

2. Risk patching

For the current situation of non-standard systems, in addition to a complete systematic solution, we can also do some patching solutions.

1) Metadata tagging

Sort out the existing systems that can connect to standardized schemes for tagging, and the subsequent incremental systems need to be updated through reminders to R&D applications and automated inspections.

Main tagging requirements include:

(1) Whether to connect SSO authentication

This is an important link in the system risk assessment. Only when authentication is connected can it be included in the complete unified identity management solution. If in addition to connecting SSO, it is necessary to retain the original authentication entry, it needs to be marked as 'coexistence'.

Data tagging suggestion options: Yes/No/Coexistence.

(2) Whether to involve permission分级

Firstly, such systems may have unauthorized access vulnerabilities, so this field is also the basis for automated scanning rules and manual security testing.

Secondly, if such systems involve complex permission models, building a set of permission systems is costly, and it is not transparent to the security/risk team. Not doing the tagging well will take many detours in auditing and tracing.

Data tagging is recommended as an optional item: yes/no.

(3) Whether to connect permission control

This is a supplement to the previous item 'Whether to involve permission分级'. Systems that involve permission分级 but do not carry out standardized control are also at risk.

Data tagging suggestion options: Yes/No/Build it yourself.

(4) Whether to connect operation behavior auditing

Of course, the cost of operation behavior auditing in the traceability system is not high. However, if the daily construction is not done with the logs/traffic of security alerts, it can be a very time-consuming task when something goes wrong.

Therefore, for important systems that have not been connected to operation behavior auditing, it is necessary to promote coverage based on tagging.

Data tagging is recommended as an optional item: yes/no.

(5) Whether involving cooperative party accounts

If there is a risk with internal accounts, we can easily locate the person/IP/device.

However, if it involves accounts of cooperative parties, such as group headquarters/subsidiaries/suppliers/units, etc., it is difficult for us to trace and locate them effectively in the first time, so for such scenarios, we need to consider additional strategies.

Data tagging is recommended as an optional item: yes/no.

2) Exposure surface protection

(1) Bastion host/VPN/remote desktop

Protecting from the channel level can narrow the exposed surface and further refine control.

This is similar to adding an extra layer of shell to the unified identity management solution, but the disadvantage is that the cost is relatively high.

(2) Whitelist/Physical isolation

The whitelist generally refers to IP/port whitelist, which is a common emergency response plan.

Physical isolation is only used for high-security systems, but in view of the increasingly prevalent HW actions, a stricter control strategy is not a problem.

(3) Avoid direct access to backend interfaces from the office network

If I were an attacker/hacker, I would first consider targeting the office network.

However, if the system does not have authentication/authorization, it is recommended to be cautious when opening it to office network users.

Without effective monitoring and auditing means, this is equivalent to leaving a backdoor for attackers/hackers.

The security strategy of production machines is generally strict, and test servers don't have much, but office network PCs can be easily compromised with a 1-day attack.

Office network PCs may have a whitelist for accessing systems, which also stores a lot of sensitive information, which is friendly to attackers/hackers, but it is necessary to pay attention to antivirus software and terminal monitoring when controlling the machine.

3. Solution design

In actual situations, we need to adapt to local conditions and carry out transformations, and strengthen security through unified identity management solutions.

1. Authentication control

• Pain point status:

For non-standard systems, it is difficult to integrate or connect with the SSO authentication system; for standard systems, there are also many irregular cases of connecting to the SSO authentication system.

• Governance direction:

Complete the standardized authentication transformation, ensure the basic security strategy, and create a trusted system.

1) Authentication transformation

It is required that self-developed R&D or suppliers provide support and join the support for the existing SSO authentication system.

Of course, this is the most costly, and the existing login system can be retained as a fallback option, but it requires that operations need to be audited by the security platform and included in controllable management.

2) Strategy control

Through the issuance of system specifications, require the R&D team to make corrections until the basic security strategy of the system meets the security standards.

This belongs to a management-level solution, but it is indeed effective. It can solve problems through personnel allocation, which is also a good method.

3) Certificate verification

Establish a trusted certificate issuance mechanism within the intranet, use a certificate center for unified verification, and only after passing can trusted interactions be carried out.

When studying Google's solution earlier, it seemed quite interesting. However, considering that the cost is relatively high even for implementation within the intranet, it can only be placed in the medium-to-long-term plan.

4) Authentication Isolation

Currently, the SSO authentication within Company Y is relatively complex. If the existing authentication isolation is not completed, the subsequent governance work will be more麻烦.

(1) Intranet/Extranet

As mentioned earlier, Company Y is a subsidiary of a central enterprise, and its group headquarters also has a general SSO authentication system.

Some systems need to be provided as open platforms for access by the group headquarters and other subsidiaries, and some systems must be placed on the public network due to business requirements.

Therefore, in the governance phase, it is necessary to focus on promoting the SSO authentication coverage of the group headquarters' external network systems, while promoting the coverage of Y Company's internal network systems with its own SSO authentication, and promoting dual SSO access compatibility if necessary.

(2) Production/Testing

Y Company currently has a variety of system environments, which can generally be included in the production/test two sets of internal SSO for authentication management.

However, some systems have special characteristics and may not strictly comply with the environmental requirements for isolation. Some systems in the production environment are违规 installed in the test environment for convenience.

The permission security level of the test environment is generally relatively open, which is obviously not conducive to the protection of production data, so it needs to be sorted out and isolated separately.

In reality, not all systems can be ideally differentiated.

Some systems belong to tool platform systems and need to be interconnected with the production/test environments. Some systems are non-standard systems and cannot be modified at the code level.

Therefore, for such special scenarios, it is advisable to consider isolation and protection from the exposed surface.

2. Account Control

• Pain point status:

The account system of Company Y is relatively complex. In addition to its own basic account system, it also needs to connect with the group headquarters and other subsidiaries as well as partners, making it difficult to complete standardized account management.

• Governance direction:

Promote the modification of non-standard systems, strengthen the data adaptation of the cooperative account system, and improve the control of account passwords.

1) Data Synchronization

For systems with a certain number of users but are not easy to modify, it is impossible to use only the existing account system. In such cases, it is not easy to trace the production accidents.

If it is indeed impossible to access the unified identity management solution, consider synchronizing the necessary users from the metadata platform to the local, maintaining a separate shadow account system independently, which is also a relatively lightweight solution.

2) Co-existing Authentication

For systems with special requirements, the existing account system cannot be abandoned in the short term, but can be partially developed and modified.

In this case, we can maintain two co-existing authentication systems, open to the public with SSO authentication, and downgrade to local authentication when necessary. However, it is important to note that:

(1) The existing account system needs to follow the basic security policy.

(2) Systems with co-existing authentication need to be tagged on the metadata platform.

(3) Conduct regular security audits for systems with co-existing authentication.

3) Password Policy

In terms of account management, strict password policies are needed.

(1) The lifespan of passwords cannot exceed XX days.

(2) New passwords cannot be the same as the last N passwords.

(3) Passwords can only be composed of letters, numbers, and special characters, and the total length and the proportion of each digit need to be limited.

(4) It is not allowed to have continuous N digits of letters or numbers.

(5) It is not allowed to use the pinyin of names, common English words, or as part of the password.

4) Partner accounts

For partner accounts, corresponding regulations also need to be strengthened:

(1) The lifespan of partner accounts cannot exceed XX days, and they need to be approved before they can continue to be used.

(2) Partner accounts need to use bastion hosts/VPNs/remote desktops.

(3) Set up separate groups for control of partner accounts, maintaining relatively minimal permissions.

5) Shared accounts

For the situation of multiple people sharing accounts, it also needs to be standardized:

(1) Adding tokens/OTP authentication can limit the cost of account misuse.

(2) The system explicitly promotes that shared accounts are illegal operations.

(3) The account is bound to MAC address/IP address, and异地 login requires reporting.

(4) The account can only be alive for one time for no more than xx minutes.

(5) If the account is alive for more than xx hours, it must be re-authenticated forcibly.

3) Permission control

• Pain point status:

If you are just a tool system, you may not even need an authentication mechanism, and the definition of security margins becomes a very headache issue. The need for permission control mainly depends on the complexity of the system. If the system belongs to an open platform or a centralized platform, it may involve more control requirements.

• Governance direction:

Choose standardized permission control products to promote the rectification of systems with permission level requirements and existing defects.

1) Self-built permission system

For systems with self-built permission systems, they need to be rectified to meet the basic security strategy, of course, they can also choose to connect to standardized permission control products.

2) Involves permission levels

If the system involves permission levels, the best way is not to let them make corrections on their own, but to promote the integration of standardized permission control products.

Achieving unified and standardized permission control not only makes risks transparent and visible but also allows for short-term unified repair in the event of vulnerabilities.

In addition, establishing temporary permission groups for external accounts and independently implementing lifecycle/role/interface/data access control strategies can make it easier for IT departments to maintain. This can flexibly assign permissions for account roles while minimizing relative permissions.

Of course, choosing to connect to standardized permission control products definitely has its disadvantages.

For example, when it comes to compatibility issues, we all know that any product is difficult to support all the systems that should be connected in the ecosystem.

However, it can provide services to the system in special situations by caching permissions locally and synchronizing data.

For example, after a vulnerability is found in a permission control product, the entire permission system is at risk of collapse.

But in such cases, the other three major elements of the unified identity management plan can stand out and play a balancing and supporting role.

Through means such as audit alarms, authentication upgrades, and account restrictions, even if the authority system is overwhelmed in a short period of time, it will not fall into an uncontrollable state.

4. Audit control

• Pain point status:

When implementing a unified identity management scheme, due to the lack of operation and scattered control power, auditing has always been in a relatively neglected state.

• Governance direction:

By enriching audit sources and rules, sensitive information operation behaviors can be detected in a timely manner, and the monitoring work can be implemented effectively.

1) Operation behavior log audit

Code埋点 at the interface level, record login/logout and other sensitive operation behaviors, and monitor with risk audit rules to ensure that anomalies can be discovered as early as possible in the entire process.

2) Traffic monitoring

There is no record of HTTP BODY in the standard WEB log, but many important information exchanges of systems indeed can only be communicated based on HTTP BODY.

We can carry out sensitive information screening in communication traffic, such as investigating whether there is password transmission in the traffic.

At the same time, for traffic that does not have a certified state but contains sensitive information, it is also necessary to carry out daily inspections and reviews to uncover potential cases of sensitive information leakage.

Of course, if expanded, it can be extended to UEBA or other standardized audit products such as network layer NAT, but the detailed product introduction does not belong to the scope of this article, so it will not be elaborated further.

4. Implementation

The previous content briefly explained the design scheme, but in fact, diverse resistances will be encountered when it is implemented.

So here is a supplement on how to implement management measures.

Before the special project starts to be implemented, it is necessary to have a clear disposal plan for the systems to be included in the control range.

1. Reasonable event-driven

We cannot start the security special project just by thinking with our heads; it must have a reasonable background to tell a good story.

The background can be common industry risks, multiple homogeneous security incidents, or audit and supervision requirements, but it must be reasonable and reasonable to obtain the leadership's sword of Damocles.

2. Prioritize the standardized program

After obtaining the authorization for project launch, it is indispensable to formulate a standardized program, and a reliable test acceptance report is also an important endorsement.

In addition, it is also necessary to go through multi-party authoritative review and authorization to confirm that the scheme has the conditions for implementation.

3. Handling of abnormal scenarios

What kind of rectification goals should be included for scenarios that cannot be rectified, and what kind of process handling should be carried out, are all issues that need to be considered.

Of course, in the early planning stage, there are bound to be unforeseen difficulties. However, with appropriate emergency plans, disposal plans can also be quickly confirmed when needed.

4. Follow-up of system norms

In the internal special governance, there must be a system of norms to rely on, with standardized authority control as the guiding principle, and clear clause requirements.

If there are no existing clauses, it is necessary to apply for authorization to revise from the relevant field responsible person, and implement the project according to the final clauses.

5. Specialized Decomposition

1) Phased Execution

For complex situations, governance cannot expect to be transformed in one step. It is necessary to execute phased execution and agile iteration.

(1) Early stage

Mainly focus on the guidance of pilot system rectification, and the cycle may be slightly longer than expected. At this stage, it is necessary to focus on collecting R&D feedback and optimizing processes and solutions.

(2) Mid-term

Relatively mature experience and solutions have been accumulated, and it belongs to the rapid transformation period. At this stage, the standardized scheme is mainly promoted within a controllable range, and the standardized closing work is carried out.

(3) Post period

The standardization transformation of the system is about to reach a bottleneck. At this stage, the closure management is mainly carried out through processes, and risk compensation measures are used to dispose of the remaining systems.

(4) Closing

For systems that have been transformed, it is not a one-time solution. It is necessary to carry out regular sampling inspections to verify whether the long-term work conforms to the standard security strategy. Systems that have leaks will also be required to continue rectification.

2) Field Division

(1) Establishing a Virtual Committee

The committee needs to join the interface people and Leaders of relevant teams, and ensure the smooth execution channel by realizing the A/B roles as backups.

(2) Establishing a Weekly Meeting Mechanism

Regularly check the project progress, and discuss the disposal plan for difficulties encountered in a timely manner. When faced with irresistible resistance, report to the leadership for more resources and authorization permits.

(3) Establishing an Implementation Leader Mechanism

For coarse-grained key technical solutions, we also need to follow up and review the acceptance regularly. If deviations or improvements are found during the implementation process, corrections can also be made on the track in a short period of time.

(4) Arranging Specialist Connection

Each business line is arranged to be connected by a specialist, regularly collect and report progress data, and convey the demands of business and R&D.

At the same time, the specialist needs to timely feedback the difficult solution solutions given by the project group to R&D, and focus on promoting new work content.

6. Multi-dimensional Drive

1) Top-Down Promotion

It is best to promote the key nodes of the project from top to bottom. With the support of responsible persons in various fields, the R&D implementation effect can at least reach the qualified level.

2) Audit Supervision Pressure

Internal audits and external supervision will regularly issue materials for inquiry. Even if there are problems in the implementation process of R&D, at least it will ensure that the rectification reaches the level recognized by audit supervision.

3) Hard Index Assessment

By reporting the project initiation, strive to join the annual assessment of the R&D line. Use performance coefficients to effectively drive the quality of R&D implementation, thereby ensuring effective control over the final results.

4) Layered Accountability

If there are delays in delivery, imbalances in quality, or lack of cooperation in execution during the project implementation, penalties need to be enforced on individuals through a hierarchical accountability mechanism.

V. Conclusion

This is the implementation of the analysis of the unified identity management scheme. Due to the wide scope involved, the design description of specific technical solutions may not be very detailed.

If there is an opportunity to encounter more interesting content later, it will be updated accordingly. Thank you!