In mid-2020, onewhite hatThe credentials used by a backend system of a new energy car company were discovered on GitHub. The credentials simply used Base64 encryption. Although this credential cannot directly log in to the corresponding backend system, the white hat successfully found several unauthenticated interfaces through the API list it obtained. Through these interfaces, the backend data can be obtained in batches.
This potential crisis should have sounded the alarm, but in August 2020, the car company encountered a similar safety incident again. The car owner revealed that several other people’s cars appeared on his vehicle management app. Although the car owner reported it to the car company, the car company silently fixed the problem. After analysis, the white hats agreed that this problem is another typical interface lack of authentication vulnerability.
With the rise of cloud services, traditional enterprise architecture has formed the currently common cloud + local hybrid deployment form, and network architecture has also changed towards hybrid deployment. Traditional security defenses are no longer sufficient to deal with threats in hybrid deployment.
The essence of attack and defense is information asymmetry, while the essence of vulnerability is the lack of effective control of data entry and exit. In the current hybrid deployment situation, "I know which entrances and exits of my enterprise assets have problems" is extremely important.
Industry pain point: Take stock of "how much money" you have
How to solve this problem, each enterprise has its own exploration and practice. However, from the perspective of Alibaba Security, the root of the problem is that companies cannot control their own assets in real time, especially those under a co-location structure. It's that I "didn't know" I had these interfaces, or I "didn't know" there were security issues with these interfaces.
Of course, knowing what entrances and exits I have is not enough. When assessing business risks, I will find that a bunch of questions have not been answered:
l How big is the risk? What is the impact?
l How much does the current protection strategy cover?
l How to judge whether the strategy is effective?
l Are there any missing assets?
l How much room for improvement is there?
This series of questions needs to be answered with specific safety data, but the reality is not optimistic at all.
Different types of asset data are scattered in various business lines. First, it is difficult to collect and integrate. Second, it is difficult to understand and digest. At the same time, it is difficult to accumulate experience as a whole. It is difficult for different business lines to reuse each other's business results.
We are looking forward to such an "angel colleague". She has all the "asset data" I need. She has helped me correlate and analyze the data. She can also precipitate and mark the data according to the business scenarios she supports. , you can completely reuse her methodology. Not only can it be used directly, but you can also freely combine it as needed.
"Asset Blueprint" is committed to becoming such an "angel colleague".
Solution to Asset Blueprint
In March 2020, Alibaba released a new generation security architecture for digital infrastructure. Under the new security architecture, when we rethink how security defense should be implemented, we urgently need a quantifiable driving system that can be explained by data to provide data input. The biggest goal of this system is to use data to drive security defense trends. This is the background for the birth of the blueprint.
Blueprint is an asset collection system that focuses on sorting out, inventorying, and managing large-scale enterprise intranet assets. It can be used to discover various basic asset information, asset fingerprints, and data flow relationships between assets in the enterprise intranet; it also provides multi-dimensional labeling. The asset list is published as a tagged asset catalog to meet the rapid construction of various analysis application requirements proposed by the business, allowing assets to flow and be utilized, so that data comes from the business and is ultimately used by the business.
The construction of the "Blueprint" has currently gone through four stages:
The first stage, basic asset inventory, requires a clear inventory of asset scope, status, security prevention and control, and understanding of the host, application, storage, middleware, supply chain, source code, permissions and other related resources within the enterprise.
The second stage, related asset inventory, requires inventory of access relationships and association relationships between different types of node assets.
The third stage, inventory of blood assets, requires analyzing the flow paths of data in the north-south direction (network boundary from outside to inside) and east-west direction (cross-application resources, cross-node access), and drawing the boundary range and link blood flow between assets. relation.
The fourth stage is tag asset inventory. After asset data supports business needs, targeted data tags are precipitated to maximize value.
One of the reasons why Blueprint chose this stepped development plan is that each stage supports each other, but the results of each stage are relatively independent and deliverable. The advantage is that as each stage of construction is completed, the results of each stage can be quickly delivered and quickly used by the business. For example, in the "basic assets" inventory stage, hosts and applications can be quickly delivered to the business for asset inventory. After completing the inventory of basic assets, the association relationship between the host, application, domain name, and person in charge can be established, so that security emergency response and traceability can be quickly carried out. The entire asset market allows business parties to clearly see the current full picture of assets, and even see the current safety level, asset management level and corresponding risks through the market.
Bloodline asset inventory is an amplifier of the value of the entire system. If the first two nodes are logistical support, then after the third stage, the blueprint stands in a trench with the frontline security team and can directly output digital "munitions." Once an attack is discovered, based on the IP address being attacked, security personnel can quickly locate the first- and second-level impact areas that may be affected by the server, and quickly assess the attack risk based on the application levels corresponding to the first- and second-level affected machines.
Challenges and Risks
Although the internal development of the blueprint can be said to be smooth sailing, occupying "the right time, the right location, and the right people", it still faces huge challenges in actual development.
Challenge 1: “Usable”
No one knows in advance what asset data the business needs.
When business parties need to inventory assets, in most cases the asset data required is large and complex, including not only the clearly defined asset range, but also supply chain relationships, special middleware, niche code frameworks, etc. The absence of data means that the business side cannot be effectively supported. In addition to having a standardized asset data output process (data self-service application, interface or view output asset data) to meet the needs of most businesses, the blueprint also needs an entrance to customized needs, which is not clear to the business parties themselves. For asset data requirements, detailed communication needs to be done with the business side, and the required asset data must be understood together with the business.
Finally, the blueprint then searches for and introduces or produces the asset data needed by the business side. In this process, on the one hand, it meets the needs of the business, and on the other hand, it also fills the asset data gap of the blueprint itself.
Challenge 2: “Dare to use”
Without accurate data, there is no value.
In fact, many companies have done asset inventory, but most of them have not "implemented it". The root cause is that the asset data is not "accurate" (accurate and recalled), or the upstream assets are not accurately recalled, causing the downstream business to be unable to be used stably.
The solution provided by the blueprint is to invest appropriate resources in the construction of quasi-zhao. Relying on its own experience in asset data inspection, it has developed a configurable automated call-in inspection system with blueprint characteristics. This system can be used to complete the following inspections and calls-in:
l Basic quality monitoring, mainly including rule configuration precipitation and monitoring and alarm handling for completeness, accuracy, consistency, and timeliness. The rules are divided into general rules and custom rules.
l Multi-source cross-validation enables comparison and verification of multiple sources and asset data & link data, accurate call value calculation, abnormal data monitoring and alarm handling, and supports custom SQL to meet the diverse cross-validation needs of operations.
l benchmark sample library, supports sample precipitation and use of assets & links, and supports cross-validation and scan verification based on the sample library.
l Manual verification process. For things that cannot be automatically verified, outsourcing resources are invested, a certain number of samples are taken, and manual verification is performed.
Challenge Three: “Easy to Use”
The value of asset data is not listing but processing.
Even if there is comprehensive asset data, and each asset data can be accurate, if it is just a simple list, the inventory results will not be of high value. The value of asset inventory must be reflected in the results of correlation and processing.
Blueprint obviously will not position itself as a simple asset data stacking platform, but how to achieve the amplification effect of 1+1>2 has always been a difficult problem in the field of asset inventory. The entrance to the blueprint is bloodline data.
Through the code analysis capability of the self-built blood link, complete the automated analysis of the application code, extract information such as interface calls, middleware usage, DB usage, etc. in the application, and then combine it with traffic, application and other information to generate call links and data links. Road data not only solves the problem of north-south boundary information flow path description, but also improves the information flow path between east-west applications.
Then combine online information, offline information, and blood relationship analysis between offline information to generate blood relationship data and grasp the flow path of data in the DB.
Finally, the application data link/call link, coupled with data lineage data, truly realizes omnidirectional data flow path analysis from the interface to the database.
Much of the value of the data lies with the second user.
While serving the business side, the blueprint actively accumulates actual business usage needs and experience. Based on standardized basic data, it builds asset tags with business attributes, reuses multi-party business effects, and maximizes the value of business governance.
For example, when serving content security risk business scenarios, the blueprint marks interfaces with content addition and modification logic from a technical level, and then marks the interfaces based on the specific use of the business. The blueprint is combined with the improved logic to mark other interfaces. In another project, this batch of tagged content addition and modification interfaces can be directly used as the established interface scope, and can be focused on secondary screening according to business needs. This not only maximizes reuse of business value, but also truly achieves reuse. From business to business.
Drive safe operations
Through four stages of development, the blueprint relies on massive asset data to establish an asset inventory system under a hybrid cloud architecture, assisting business parties to use asset data to complete various business needs such as asset inventory, risk identification, etc., and then provide standardized asset usage plans. Provide business parties with reliable, convenient and efficient access.
Ultimately, Alibaba Security hopes to drive the construction of Alibaba Security through objective asset inventory. Just like a human vein map, the blueprint can proactively identify risk issues through clear asset inventory and become a means to help various security units conduct effective security operations.
Original article by AliCloud Security, if reproduced, please refer to the source: https://cncso.com/en/alibabas-data-asset-blueprint-html