In this part we will consider. Risks of overly superficial modeling. What deep modeling looks like. Security defects in the form of broken business integrity. Risk mitigation with deep modeling. In today’s digital world, where the security of data and information systems is very important, there is a real threat of surface modeling. The risks of this approach can lead to poor security, compromised business integrity, and other serious consequences. One way to reduce these risks is to use deep modeling. Surface Modeling and its Risks: Surface modeling means creating simplified models without deep analysis and understanding of processes. This can lead to incomplete information about possible threats and vulnerabilities.
The result can be an insufficient level of security and a violation of the integrity of information systems. Deep Modeling and Its Advantages: Deep modeling involves a detailed analysis, taking into account all possible options and real risks. This allows you to identify potential problems, including security flaws, integrity violations, and the possibility of unauthorized access. Security Defects and Impaired Business Integrity: Security defects can lead to violations of the integrity of data and information systems. This can include unauthorized access, data loss and reputational damage. Disrupted business integrity can lead to large financial losses and loss of customer trust. Mitigation of Risks with the Help of Deep Modeling: Deep modeling allows you to identify potential risks and take them into account at all stages of design and development. This includes the analysis of possible threats, the establishment of protective mechanisms and constant monitoring. The risks of floor modeling can affect the security of information systems and business integrity. Using deep modeling allows you to detect, prevent and reduce risks through detailed analysis and effective protection.
This is a true story about how negative numbers can lead to big financial losses. It’s based on a problem our client had that we were working on, but in order to share the details with you, we had to distort the context. In particular, we changed the product that the company was selling: we assure you, it was not books. Interestingly, there are similar examples in which books actually appeared. Amazon faced a similar software bug about 2000. However, we do not know the details of these cases.
It’s also a story about how a serious safety problem has existed in industrial settings for a long time without drawing attention or causing any malfunctions – at least not in the technical sense. However, the company lost money because of it. In practice, it was impossible to compensate for the losses, but it was possible to reveal the identities of those who profited from this problem.
Finally, this story is about how an international trading company accidentally allowed its customers to get discounts on their own in their online store. We will show how his financial losses were the result of the superficial design with insufficient or no modeling that we often encounter. We will also illustrate the importance of clear and conscious modeling.
There is nothing special about this online store – a typical site where the customer puts books in the cart, places an order, makes payment by bank card and then receives the goods through the delivery service (Fig. 2.1).
The store opened a long time ago and continues to develop. The company invited a team of security specialists to conduct audits and testing. In particular, they check the configuration of the system in the production environment and its code base. And also perform tests, trying to manipulate the system from the outside in search of security holes. The team was tasked with investigating anything that might seem suspicious.
The analysis showed that the infrastructure is quite reliable. Following this, specialists took up firewalls and scanned the open ports of the operating system. They sent malicious packets to the web server, but it didn’t cause any problems. And it’s no wonder: these days, security problems rarely arise from infrastructure defects. Everyone already knows that objects that should not be accessible to everyone should be isolated.
At the same time, other team members were investigating the online store application from a technical point of view, trying to find ways to bypass the authentication mechanism. They checked whether it is possible to steal an open client session, tried to “poison” the cookie. And again to no avail. But even here everything was expected, since security was achieved by correctly configuring the web server, and the creators of the store clearly checked the documentation when configuring their application.
The breakthrough came when one of the team members, Joe Tester, became interested in the “Quantity” field in which the customer indicates how many books he needs on the order form. He specified a piece of JavaScript code in it to test if it would be executed. But nothing happened. He then tried to trigger an SQL injection, again without success. Finally, out of curiosity, he entered -1 as the number of copies of Hamlet at the $39 price. That is, Joe Tester tried to buy one negative “Hamlet” – anti-“Hamlet”.
To his surprise, he didn’t get an error message. The store accepted the order and completed its processing. Joe provided a credit card and received an email confirming that the order had been accepted. “Strange,” he thought. After making a note in his notebook, Joe continued his work. The next morning, there was a knock on the door of the security office, and the woman looked in uncertainly.
“I’m from the accounting department,” she introduced herself. “I wanted to ask if you know anyone named Joe Tester?” and immediately clarified, “I just asked here and someone told me what you might know.”
“Yes, this is our test client,” the team replied. “What’s wrong with him?”
The accountant continued, “I was looking at the accounts receivable journal and noticed that the system had created a refund invoice for this customer for $39. But when we were about to mail his book, a strange thing turned out: his address coincides with the address of this office.
That’s why I was wary and started asking.”
The system tried to pay money to Joe Tester. Not good.
Let’s take a step back and see what happened. The online store accepted an order with -1 copy of Hamlet, and that is certainly amazing. But let’s think about the logical consequences that this entails.
If someone buys a book at a price of $39, the order amount would be $39, so it makes sense that the customer would pay that amount to the store. In our case, Joe Tester bought not a copy of “Hamlet”, but a negative, so the amount of the order is -$39 (Fig. 2.2). He must pay the store $39, or the store must pay him $39. But the store should not pay money in this way. Perhaps it is Joe Tester who should give the store a copy of Hamlet.
From the point of view of security, this is a violation. One aspect of security concerns data integrity: this means that data must not be altered or generated in an unauthorized way. Integrity is most often seen in a technical context: providing checksums and cryptographic signatures to ensure that data changes according to rules. In our case, it is not about technical, but about business rules. Send money to customers for antiquarian books – Not a good business model. We are dealing with a breach of business integrity.
Alerted, the security team launched an investigation to find out what was really going on. It turns out that the system of the online store calculates the amount “To be paid” in the amount of -39 dollars per order, which is logical, although strange. This amount is successively passed through several other systems (Fig. 2.3).
The most interesting thing in this story is that it is impossible to understand the security problem without understanding each of the systems involved in it, their interaction and reaction to external factors. Let’s start with two: the billing system and the accounts receivable journal.
The billing system is designed to collect payments from customers. If a customer prefers to pay by credit card and places an order of $347, that amount will be charged to their credit card. But the customer can choose other payment methods: invoice, savings account or gift cards. Some customers have different payment methods for different amounts. Large orders can be paid directly, and small orders can be accumulated on an invoice issued at the end of the month.
Joe Tester places an order for -$39, and this amount is transferred to the billing system. It has a credit card module that doesn’t know what to do with negative amounts. From a billing perspective, a negative amount means you don’t need to accept anything for payment. The payment procedure is skipped.
Now let’s move on to the accounts receivable journal. This journal is part of the accounting system and contains records of customers who owe the company money, the debt exists between the purchase of the book and the receipt of payment in the company’s account. The accounts receivable journal has a balance for each customer. For example, if someone places an order for $347 and chooses to pay the invoice, $347 is added to the customer’s balance. Later, when the company receives payment, the journal balance is reset to zero. Sometimes people overpay—for example, we could pay $350. In this case, the balance becomes negative, -$3, which means: the company owes money to the client. From the bank’s point of view, the company’s debt to the client is quite normal, even in the long term. But for an online bookstore, this is acceptable only as a temporary situation. If this happened, the store should try to pay off the debt as soon as possible.
In a normal situation, in order to pay off a debt to a customer, an online bookstore sends a return invoice. These accounts are processed in batches – that’s what the accountant meant when she said, “I looked at the accounts receivable journal…” When Joe Tester made his counter order, the online store’s system sent a payment of -$39 to the accounts receivable journal, which immediately created the company’s debt to Joe. The next night, the system processes the journal, finds the unpaid debt, and creates a reverse invoice to be sent to Joe to reset his journal balance. This effectively means that our test client gets paid (Figure 2.4). This is an invoice that a shrewd accountant found suspicious and had questions about.
Tests were carried out in real conditions, so it is obvious that the detected gap existed in the system for some time. This particular case was discovered only because of a suspicious address. But similar cases could have happened before.
A financial investigation was launched to determine how serious the problem was. The operations team and security teams joined forces to cross-check all invoices generated for returns. After sifting through invoices for suppliers and partners, only customer records remain. Most of them were correct and explained by product damage or other understandable reasons. There was a small part left, so the problem was not too serious – at least it seemed so at the time. However, the very fact that the free money transfer went unnoticed was surprising. The technical investigation continued to reveal all the details of what happened when the antibook was ordered. It turned out that two more important systems are involved in this process: warehouse and control room.
The most interesting thing in this story is that it is impossible to understand the security problem without understanding each of the systems involved in it, their interaction and reaction to external factors. Let’s start with two: the billing system and the accounts receivable journal.
The billing system is designed to collect payments from customers. If a customer prefers to pay by credit card and places an order of $347, that amount will be charged to their credit card. But the customer can choose other payment methods: invoice, savings account or gift cards. Some customers have different payment methods for different amounts. Large orders can be paid directly, and small orders can be accumulated on an invoice issued at the end of the month.
Joe Tester places an order for -$39, and this amount is transferred to the billing system. It has a credit card module that doesn’t know what to do with negative amounts. From a billing perspective, a negative amount means you don’t need to accept anything for payment. The payment procedure is skipped.
Now let’s move on to the accounts receivable journal. This journal is part of the accounting system and contains records of customers who owe the company money, the debt exists between the purchase of the book and the receipt of payment in the company’s account. The accounts receivable journal has a balance for each customer. For example, if someone places an order for $347 and chooses to pay the invoice, $347 is added to the customer’s balance. Later, when the company receives payment, the journal balance is reset to zero. Sometimes people overpay—for example, we could pay $350. In this case, the balance becomes negative, -$3, which means: the company owes money to the client. From the bank’s point of view, the company’s debt to the client is quite normal, even in the long term. But for an online bookstore, this is acceptable only as a temporary situation. If this happened, the store should try to pay off the debt as soon as possible.
In a normal situation, in order to pay off a debt to a customer, an online bookstore sends a return invoice. These accounts are processed in batches – that’s what the accountant meant when she said, “I looked at the accounts receivable journal…” When Joe Tester made his counter order, the online store’s system sent a payment of -$39 to the accounts receivable journal, which immediately created the company’s debt to Joe. The next night, the system processes the journal, finds the unpaid debt, and creates a reverse invoice to be sent to Joe to reset his journal balance. This effectively means that our test client gets paid (Figure 2.4). This is an invoice that a shrewd accountant found suspicious and had questions about.
Tests were carried out in real conditions, so it is obvious that the detected gap existed in the system for some time. This particular case was discovered only because of a suspicious address. But similar cases could have happened before.
A financial investigation was launched to determine how serious the problem was. The operations team and security teams joined forces to cross-check all invoices generated for returns. After sifting through invoices for suppliers and partners, only customer records remain. Most of them were correct and explained by product damage or other understandable reasons. There was a small part left, so the problem was not too serious – at least it seemed so at the time. However, the very fact that the free money transfer went unnoticed was surprising. The technical investigation continued to reveal all the details of what happened when the antibook was ordered. It turned out that two more important systems are involved in this process: warehouse and control room.
The warehouse accounting system tracks how many copies of a particular book are in stock and available for sale. To begin with, it would be possible to determine the number of pieces of each edition on the warehouse shelves, but, unfortunately, it turned out that everything is not so simple. Imagine, for example, that we have 17 copies of “Hamlet” in stock. A customer bought two of them, but they haven’t been taken off the shelf and shipped yet. These books should not be counted because they are not available for sale and the store no longer owns them. There should be 15, not 17, copies of Hamlet.
Another hypothetical situation is that the shelf intended for the novel “Pride and Prejudice” turned out to be empty. The store has already bought 100 copies from the publisher, but the truck with them has not yet arrived at the warehouse. Since these books are the property of the store, they are available for sale and must be in stock. That is, there should be 100 copies of Pride and Prejudice in stock, not 0. Many other strange situations can occur.
The warehouse accounting system has a complex logic.
After selling three copies of Hamlet, the online store will send a message to the inventory management system to reduce the number of copies of Hamlet from 15 to 12. But what if Joe Tester buys book -1 instead? The number of available Hamlet units was equal to 15 and had to decrease by -1 to 16 (Fig. 2.5). Selling one anti-Hamlet increases the number of available copies by 1!
The dispatch system ensures that customers receive their books. When an online store forms an order, the shipping system sorts its items and compiles a list according to which warehouse workers should pack the goods. This is a complex system that tries to minimize the work of employees, allowing them, for example, to collect books for several orders at once. The process is well optimized.
However, the submission system does not handle negative book counts very well. Such an item in the order leads to an exception, which is written to the system log along with many other messages. Unfortunately, no one ever looks at this magazine. The order item has actually been cancelled.
Systems believe the same lies
An interesting picture emerges. From a financial point of view, information systems are harmonized among themselves. Billing and delivery systems are not so important, as they do not change their state. We are more interested in the warehouse accounting system and the accounts receivable journal.
The warehouse accounting system mistakenly believes that there are 16 copies of Summer Hum, when in fact there are 15.
The accounts receivable journal mistakenly believes that the store owes someone money.
Financially, these facts balance each other out: instead of having 15 books and zero debt, the store ends up with 16 books and a debt equal to the price of one book. Both systems are wrong, but they believe the same lie. This illusion is consistent.
Because the systems are aligned, regular reports show no discrepancies. In fact, some are generated nightly, while others that are part of the financial statements are quarterly. And there are no inconsistencies in any of them, since they simply did not exist in the information systems. There are discrepancies, but only in the form of discrepancies between the warehouse accounting system (16 books) and the actual number of books in the warehouse (15). But it was possible to notice this only after the inventory, which is carried out at the end of the year. It involves manual counting of goods in the warehouse with subsequent entry into the accounting system. Only this would make it possible to notice the missing book.
However, there is nothing surprising in the discrepancies discovered during the annual inventory. Books are physical objects, and a lot can happen in storage. For example, a supplier may load 133 books instead of 134. Sometimes it happens that not all boxes are corrected or there is a mistake in counting. The book can be dropped, damaged and thrown away. This should be noted in the system, but sometimes people are in a hurry and forget to do it. Theft is also possible. The finance department classifies all of this as “lost to stock”, and some level of such losses is to be expected.
In fact, the annual inventory taken a few months earlier showed that inventory losses had increased. The management decided that the reason was the lack of motivation of the warehouse workers: maybe they became less attentive and damaged more books, or maybe they started stealing books. As a result, management sent them on a one-day retreat with a motivational coach to align their values with the company’s ethics. The employees of the warehouse were surprised and not very satisfied.
Upon further investigation of the discrepancies, everything turned out to be worse than it first appeared. Discrepancies detected in the warehouse significantly exceeded the total number of return invoices. But that wasn’t the end either.
Realizing that regular reports could not be trusted, the security team began an in-depth investigation. It turned out that receiving a return invoice was not the most common way of dealing with this defect. Self-made discounts in the form of adding negative books before placing an order, which reduced its total amount, were much more popular (Fig. 2.6). Apparently, rumors about this unusual opportunity spread on the Internet, as many customers took advantage of it.
The investigation revealed that the company lost a significant amount of money due to this loophole. It’s time to decide what to do about it.
We will return to the technical defect a little later. But what about the money customers owe the company by giving themselves discounts? Ultimately, the board of directors makes the decision. After careful analysis of the situation, it was decided to leave everything as it is. Going after customers, many of whom are repeat customers, will make them resent the company and do more damage than simply accepting the loss, patching the hole and moving on.
The continuous violation of business integrity continued for months, despite the fact that everything was formally in order. And this, most likely, would have gone unnoticed if not for an inquisitive accounting employee and a security tester who was interested in business processes (a subject area related to the sale of books). We are convinced that many such defects can be found all over the world today, which are constantly used without causing any suspicion.
Obviously, a company that loses money like this has a security problem. But where does it all start? And more importantly, how do you avoid it? Our observations show that similar situations are often the result of a modeling process that prematurely stops at the first more or less suitable model. Such a process is characterized by insufficiently deep analysis, uncritical approach, lack of planning and discussion. We will specifically call this the surface modeling style (which is the opposite of deep modeling).
To begin with, let’s ask ourselves: “What could cause such a problem?” Looking back, we realize that the number of books could not be made an unlimited whole number. But why was this aspect designed the way it was? As mentioned in Chapter 1, design encompasses all the conscious decisions that are made in developing software. At the same time, as part of the design, it was deliberately decided that the value should be in the form of an unlimited integer. It may not have been a well-thought-out decision, but whether you like it or not, someone made it.
Let’s look at other concepts related to design – there are quite a lot of them in the field of book sales. Some of them are important, others not so important. In the design process, we choose concepts that will play a central role, such as order, order items, book and quantity. It is often necessary to observe how the design focuses on the question “How to reflect this in the code?”. In such cases, project decisions are reduced to finding ways to implement concepts. When such a method is found, the work can be considered complete. And in this case, the shortest path from business concepts to code is achieved by using elementary language types: integers, floating-point numbers, Boolean values, and strings (Fig. 2.7).
Aspects of the domain are presented in different ways: some explicitly, others implicitly. For example, our model has such a thing as an order, and an order has a monetary value. It also contains items, each of which has a book and quantity. The book has a title, an ISBN, and a price. Orders, product orders, and books are obvious concepts in our subject area. And quantity, name, ISBN and price are implicit concepts and are represented by integers, strings, etc. In other words, quantity is an integer without limits. Looking at things this way, it may seem strange that both the order, the order item, and the book were detailed, and the quantity remained a simple whole number. Why did this happen?
It seems to us that many of these errors are due to the fact that the modeling process was not completed or was not carried out at all. Imagine a conversation between a salesperson named Mark Etolog and a developer named Cody Rovshchik in the early stages of a project. They might have something like this dialogue.
“And then you can add the books to the order,” Mark says.
“How can we describe the book?” Cody asks.
“Printing the name and price,” Mark replies.
“What can the price be? Is it always an integer?” – Cody does not calm down.
– Well, no. A book can cost, for example, $19.50 excluding taxes,” says Mark.
Cody states, “As attributes, a book has a name and a price. The header will be a string. The price will be real, not an integer.”
CAREFULLY. Never, under any circumstances, imagine money as a floating point number! To find out why, read the sidebar “Money and Double Type” in Chapter 12.
Cody asks, “Is it all about the book?”
“No,” replies Mark, “it’s also important to include the ISBN so we can separate the hardcover and paperback books.”
“Okay. Then we add books to the order,” says Cody, “like Moby Dick, Pride and Prejudice, Hamlet, Moby Dick Again, 1984, and Moby Dick Again?”
– Well, almost. We’re just listing three copies of Moby Dick, and we don’t care what order they’re bought in.
Okay, Cody thinks, that’s not a real number, that’s an integer.
CAREFULLY. Be suspicious of simulations that end with “this is an integer”!
This discussion later turned into code. Cody created a Book class with title, isbn, and price attributes. A new method, addOrderLine(Book book, int quantity) appeared in the Order class. Because order, order item, and book have explicit representations, they all become classes. The type system ensures that they will be used in the appropriate parts of the code. Passing something else where Book is expected will result in a compile error.
And this quantity is implicitly represented by the elementary type int. The use of this attribute is not controlled by the type system or the compiler. You can accidentally pass in some other integer, like the temperature outside, and the compiler won’t get it wrong. That we expect to receive a quantity is indicated only by the name of the quantity argument:
It should be noted that during the conversation, Cody did not ask any additional questions about the ISBN or the name of the book. He immediately concluded that this is plain text, and in the code these attributes are represented by the String type. But the ISBN and, most likely, the name cannot be any strings.
When it comes to modeling, Cody is no slouch. He asked an interesting question about the nature of price: “Is it always a whole number?” – but did not delve deeper. Also, he completely missed the hint that the price might be more complicated when Mark replied, “… not including tax.” Coady seems primarily concerned with how it will be represented in the code, not , how it works.
We’ve seen how surface modeling leads to interesting business concepts being implemented as primitives: integers and real numbers, strings, boolean values, etc. In our experience, this kind of implicit representation is quite common. We often encounter systems in which almost everything is represented by strings, integers, and real numbers. Unfortunately, this backfires.
You already know that the simple thing of representing a value with a valid integer can cause serious security problems. This type has no important limitations. Similarly, using an unlimited number of lines for book titles and ISBNs leaves too much room for abuse. If something else is passed to a system that expects to receive a properly formatted ISBN, something strange can happen.
CAREFULLY. Any integer between -2 and 2 billion is a bad idea for most things.
A credit card number and a Social Security Number (SSN) are two more common examples of how implicit concepts can be represented as strings. Obviously, we run the risk of receiving data that is not a valid credit card number or SSN, and may even be in the wrong format. But what’s even worse is that you can handle them incorrectly.
Credit card numbers and SSNs have strict restrictions on how they can be published, logged, etc. If you present them as strings, there is a risk that they will accidentally end up in a log entry or appear on screen. Later, you will see how representing such entities using domain classes can prevent such errors. For example, we can use one-time read objects (this will be discussed in Chapter 5).
But let’s return to our concepts presented in the form of language primitives. Such notions can lead to very unattractive code. Take a look at the following method signature:
void addCust(string name, string phone, string fax, int creditStatus, int vipLevel, string contact, string contactPhone, boolean partner)
This code has only eight parameters, but if two of them are accidentally interchanged, the customer can receive a credit status or level of service to which he is not entitled. Since creditStatus and vipLevel are ints, the compiler won’t notice if you specify them in the wrong order. Such mistakes can lead to hidden defects that are difficult to detect, sometimes safety-threatening. Eight parameters is not such a long list. We encountered signatures with dozens of parameters, each of which was a string. This problem is especially common for designers.
Superficial modeling and the implicit concepts it encourages greatly increase the risk of writing incorrect and unsafe code. The alternative is a more thoughtful, in-depth approach to modeling and the use of explicit concepts. Now let’s see what this story would look like if employees consciously tried to implement deep models.
To understand what deep modeling is, you must first accept the fact that any model you create is the result of a choice. In any subject area, there are countless different potential models. In the course of designing, you choose a set of concepts on which you will build and invest a certain meaning in them. To use domain design terminology, this particular choice is the Domain Model (or domain model) – this is the required entity of the domain. Our work in security and design is largely inspired by a specific approach that encourages deep understanding and rigorous domain modeling.
Targeted efforts in the field of modeling imply active study of the subject area. One should not strive for the implementation of concepts, but understand them. This makes the discussion of the models much deeper and often leads to an iterative process consisting of communication and coding. As a result, you can highlight more concepts, without a clear idea of which it is impossible to fully cover all the characteristics of your model.
Let’s go back to the dialogue between Cody Rovshchik and Mark Ethologist and see what it would look like in the context of deep modeling.
“And then you can add the books to the order,” Mark says.
“How can we describe the book?” Cody asks.
“Printing the name and price,” Mark replies.
“What can the price be? Is it always an integer?” – Cody does not calm down.
– Well, no. A book can cost, for example, $19.50 excluding taxes,” says Mark.
Cody states, “As attributes, a book has a name and a price. The price itself looks quite complicated, because you mentioned taxes. I’ll have to think about that later.” And he asks: “Is it all about the book?”
“No,” replies Mark, “it’s also important to include the ISBN so we can separate the hardcover and paperback books.”
“Okay. Then we add books to the order,” says Cody, “like Moby Dick, Pride and Prejudice, Hamlet, Moby Dick Again, 1984, and Moby Dick Again?”
– Well, almost. We’re just listing three copies of Moby Dick, and we don’t care what order they’re bought in.
“Can I buy half of Moby Dick?” Cody asks.
– Of course not, what nonsense!
“You mentioned the word ‘quantity,'” Coady says. “I want to understand it better. What happens if you first add three Moby Dicks and then remove them all? Will we get zero copies of Moby Dick?
– Er, not really. That is, the number zero is not a value at all. We would just delete it,” says Mark.
“There seems to be some kind of rule to this number,” Cody says. – How big can it be? Two billion books?”
“Haha. Of course not. Seriously, as I recall, the flow of books passing through the store is limited and we can’t take orders of more than 240 units.
“The flow of books through the store?”
“Yes, that’s what they call it. That’s how orders made in the online store are processed in the warehouse. It’s about the sizes of the boxes, the packing house and so on. Larger orders have to be processed in bulk. But it’s not available in the online store.” Sol explains.
“What does order total mean? Can you give an example?”
“It’s just a cumulative number of books. “If you have three copies of Hamlet, four copies of Pride and Prejudice and one copy of Moby Dick, that’s eight,” Mark replies.
ADVICE. During the simulation, do not forget to discuss the upper limits – this always allows you to get interesting information. Cody notes that the individual quantity cannot exceed 240, and the same applies to the total quantity in the order.
Later, this information is embodied in the code:
In the course of deep modeling, many more interesting concepts can be highlighted that are too interesting to leave implicit. As a general rule, we recommend making implicit concepts explicit. If you encounter such an implicit concept as “quantity” in your story, take a few minutes to discuss it in more depth. If it seems interesting enough to you, make it explicit – describe it as part of your design decision. Later, when writing code, the quantity will take the form of a separate class and apply its own bounds. Also, using this concept will make the rest of the code more expressive.
A common objection is that making all these concepts explicit would result in many classes. But it should be noted that the code in these classes is needed in any case: all noteworthy business rules must be implemented in the code, otherwise the quality of the system will deteriorate. Implementing explicit concepts as classes affects the organization of your code. If the concept you are interested in is spread over several classes, it is more difficult to find.
ADVICE. When modeling, make implicit concepts explicit.
Surface modeling is a missed opportunity to learn something important. As you have seen, this can also be a potential source of security vulnerabilities. To take advantage of this opportunity, the question should be asked: “What is meant by quantity? Are there different types of quantities? Are there any limits?” You’ll likely learn that the number of books can’t be negative. You might even learn that it’s not zero, because “the word ‘quantity’ we use with a number is only when there are books, otherwise it is considered that there is no quantity at all.”
Questions about the lower bound can lead to a discussion of the upper bound. Is it reasonable to allow 2,147,483,647 books to be added to the order? After hearing such a question, a specialized expert can explain how logistics work, how books are loaded onto pallets, etc. The discussion will deepen your understanding of the processes and further reduce the risk of business integrity issues.
This design approach makes the result much more expressive, resilient and less susceptible to security vulnerabilities. In the following sections, we will try to explain how to achieve this and which design principles are most effective for avoiding vulnerabilities. Let’s start by looking at some of the domain-specific design concepts that have proven to be most useful.
Incomplete, missing, or superficial modeling leads to the emergence of a design solution with defects in the field of security.
A security defect in the form of compromised business integrity can exist in an industrial environment for a long time, causing financial losses.
Conscious, purposeful design allows for a much more reliable solution.
We used materials from the book “Security by design”, which was written by Dan Berg Johnson, Daniel Deoghan, Daniel Savano.
975 
864 
737 
700 
722 
697 
744 