Issue 48: Add business language and scenarios #56
Conversation
nekosoft
changed the title
nekosoft
changed the title
There was a problem hiding this comment.
Thanks @johndtgroup @nekosoft this is very exciting!
- Could you share your thoughts on the doc structure? How do we relate the top level description vs the gist, and the business examples vs examples?
- One suggestion on examples is that we could have the technical part of the examples be available on click for each business example. Wdyt?
- I think its clear that we need better distinctions and perhaps merging of categories 1, 2, 4 5 and 8. Could you share your thoughts on that?
- I love the fact that you added concrete business use cases for each risk, I feel like it really helps make it into a story.
content/2022/en/LCNC-SEC-03-Data-Leakage-and-Unexpected-Consequences.md
Outdated
Show resolved
Hide resolved
content/2022/en/LCNC-SEC-04-Authentication-and-Secure-Communication-Failures.md
Outdated
Show resolved
Hide resolved
content/2022/en/LCNC-SEC-08-Data-and-Secret-Handling-Failures.md
Outdated
Show resolved
Hide resolved
content/2022/en/LCNC-SEC-08-Data-and-Secret-Handling-Failures.md
Outdated
Show resolved
Hide resolved
content/2022/en/LCNC-SEC-10-Security-Logging-and-Monitoring-Failures.md
Outdated
Show resolved
Hide resolved
|
Michael,
I didn't discuss it with Yianna, I look forward to her thoughts.
See my thoughts below. What do you both suggest as a next step?
1. Doc structure. I would try to keep the 'business language' sections
together as an introduction. We tried to write the gist and examples in a
way that they are clear to a business user but also clear to a technical
reader. So, using those as the intro works for all readers. We could
then have the more detailed description (with maybe a note the following is
for security experts) that gets more technical.
As far as more technical examples, I think they should be included as
well. In discussing with Don Willits, he has specific technical concerns
that go deeper than what Yianna and I attempted to explain, but are very
meaningful to him. I expect that is true of many in his situation.
Talking about those specific and technical examples would add significant
value.
Maybe:
Gist
Business Scenarios
Deeper Dive (technical details)
Technical scenarios
References
Identification and Remediation approaches (how to prevent)
- I would like to take a crack at rewriting this section with Yianna
to discuss how to best identify/fix these risks and what to do at what
'layer(s)' of the organization to help remediate the risk. Assuming 3
main groups: Citizen Developers, Center of Excellence, IT (or outsourced
vendor in the case of Zenity)
- For example Account impersonation:
- Citizen Developers:
- Train developers on the concept and best practices. For
example when using automation, attended processes should use the
credentials of the running user, so the bot's
actions/privileges will be
tied to the running user. For Unattended, each License/Bot should be
treated as a digital employee. As such, they should have
dedicated user
credentials as any human employee would have, and those
credentials should
be used for all unattended processes
- COE:
- Training in the concepts and include questions about
credenails in any deployment checklists or pre-deployment
questionnaires.
- Recommend periodic code audits to review code usage of accounts
and adherence to the policy
- IT/Vendor:
- This is where I am unclear on what something like Zenity can do
to "find" when this is happening, but would like to understand and add
more.
2. Merging categories: I was very confused by the overlap of these when I
began, but now that I have worked with Yianna, I understand these as
separate items that deserve to be addressed each on their own. I would
reorder them a bit. I think authorization/authentication are natural
pairs, and should be together.
- Account Impersonation
- Tracking who did what in the system
- Authorization Misuse
- What systems/data you should be able to access
- Authentication Misuse
- What you can do to the systems/data you can access
It is interesting how one can lead to the other, and often do. Also in the
Remediation section, I think there will be general approaches that may
address a few of these at the same time.
Thank you,
John
…On Tue, May 2, 2023 at 8:20 AM Michael Bargury ***@***.***> wrote:
***@***.**** commented on this pull request.
Thanks @johndtgroup <https://github.com/johndtgroup> @nekosoft
<https://github.com/nekosoft> this is really exciting!
1. Could you share your thoughts about doc structure? How do we relate
the top level description vs the gift, and the business examples vs
examples?
1. One suggestion on examples is that we could have the technical
part of the examples be available on click for each business example. Wdyt?
2. I think its clear that we need better distinctions and perhaps
merging of categories 1, 2, 4 5 and 8. Could you share your thoughts on
that?
3. I love the fact that you added concrete business use cases for each
risk, I feel like it really helps make it into a story.
------------------------------
In content/2022/en/LCNC-SEC-02-Authorization-Misuse.md
<#56 (comment)>
:
> @@ -11,6 +11,8 @@ title: "LCNC-SEC-02: Authorization Misuse"
| --- | --- | --- | --- |
| 3 | 3 | 3 | 3 |
+When writing an application, it's critical to define what users can access the system (Authentication) and what they can do when using that application (Authorization). Authorization misuse occurs when the application incorrectly defines what a user can do in the system.
I find the authentication description confusing because the question of
which users have access to an app can also be considered part of
authorization
------------------------------
In content/2022/en/LCNC-SEC-03-Data-Leakage-and-Unexpected-Consequences.md
<#56 (comment)>
:
> @@ -11,6 +11,8 @@ title: "LCNC-SEC-03: Data Leakage and Unexpected Consequences"
| --- | --- | --- | --- |
| 3 | 2 | 3 | 3 |
+Data leakage occurs when data ends up in locations not intended and often not appropriate, which can lead to unexpected consequences.
One thing I would mention that leakage is focused on data moving outside
of corp's control
------------------------------
In
content/2022/en/LCNC-SEC-04-Authentication-and-Secure-Communication-Failures.md
<#56 (comment)>
:
> @@ -34,6 +36,15 @@ A developer uses admin credentials to create a database connection.
They build an application that uses that connection to show data to its users.
I know this is unrelated and is not part of the change, but scenario 2
doesn't really fit here, right?
------------------------------
In content/2022/en/LCNC-SEC-06-Injection-Handling-Failures.md
<#56 (comment)>
:
> @@ -36,6 +38,16 @@ Even though the platform sanitizes form inputs for SQL injection attacks, they a
An attacker takes advantage of this and inputs a macro that gets written into the CSV file.
A user opens the CSV file to analyze user forms, and the macro gets executed.
+## Example Attack & Misuse Scenarios - Business Users
+
+### Scenario #1
+
+A user builds an online feedback form for an ecommerce store. A malicious user fills out the form using their knowledge of database commands that updates the prices of an item from $1,000 to $1. The hacker then buys the $1,000 item for $1, costing the company $999.
+
+### Scenario #2
+
+A user builds a registration form for new users. A malicious user uses their knowledge of database commands to delete all users from the database. Users with pending orders try to check on the status of their orders, to be told their account doesn't exist.
I suggest adding that the hacker does this by crafting a specific form
submission like the previous scenario
------------------------------
In content/2022/en/LCNC-SEC-06-Injection-Handling-Failures.md
<#56 (comment)>
:
> @@ -36,6 +38,16 @@ Even though the platform sanitizes form inputs for SQL injection attacks, they a
An attacker takes advantage of this and inputs a macro that gets written into the CSV file.
A user opens the CSV file to analyze user forms, and the macro gets executed.
+## Example Attack & Misuse Scenarios - Business Users
What did you think about scenario 1 above?
------------------------------
In content/2022/en/LCNC-SEC-08-Data-and-Secret-Handling-Failures.md
<#56 (comment)>
:
> @@ -11,6 +11,10 @@ title: "LCNC-SEC-08: Data and Secret Handling Failures"
| --- | --- | --- | --- |
| 3 | 2 | 3 | 3 |
+All applications store or use data, and some of that data is more sensitive than others. If a developer is unaware of what data is considered “sensitive data”, or the processes to protect that data, the sensitive information could be exposed.
Most rather than all?
------------------------------
In content/2022/en/LCNC-SEC-08-Data-and-Secret-Handling-Failures.md
<#56 (comment)>
:
> @@ -43,6 +47,16 @@ A developer creates an application using a custom API and hard-codes the API key
Other developers can access the API key directly.
Moreover, the API key might leak to the app's client code allowing users to gain direct access to the key.
+## Example Attack & Misuse Scenarios - Business Users
+
+### Scenario #1
+
+An application is developed, which stores credentials in a database. The database stores passwords in a human readable format, allowing anybody to view them. An employee with access to this database can view the password of every employee within the company, including highly privileged administrative accounts.
+
+### Scenario #2
+
+A new application is built that stores personal data about EU residents. The developer is unaware of the GDPR rules that allow a user to have their personal data deleted upon request, so never builds a process to support that need. Rather the requests are processed manually and inconsistently, leading to fines, and later a ban from doing business in the EU.
I think this part is somewhat too harsh :)
"and later a ban from doing business in the EU"
I also suggest mentioning uncomfortable questions asked by auditors
------------------------------
In content/2022/en/LCNC-SEC-10-Security-Logging-and-Monitoring-Failures.md
<#56 (comment)>
:
> @@ -11,6 +11,8 @@ title: "LCNC-SEC-10: Security Logging and Monitoring Failures"
| --- | --- | --- | --- |
| 2 | 2 | 3 | 2 |
+When an application runs, it's critical to know what ran and the actions it took (also known as an audit trail). This is often done using logging of specific actions. This risk occurs when running these systems log too much or too little information.
Maybe we could also mention that in case of a breach, this audit log would
be key to understand what happened and how to recover
------------------------------
In content/2022/en/LCNC-SEC-10-Security-Logging-and-Monitoring-Failures.md
<#56 (comment)>
:
> @@ -38,6 +40,18 @@ Developers would have to review each application version manually to locate the
Since every application "save" translates to an update, the number of updates would make a manual process prohibitively expensive.
On some platforms, developers can only review the application's current version, so they won't be able to find or revert to a stable version.
+## Example Attack & Misuse Scenarios - Business Users
+
+### Scenario #1
+
+A developer builds an automated process to load data into a financial system to complete order processing. The process handles around one thousand transactions per week with a 97% success rate. The 3% that fail are processed manually off of a daily Failed Transaction email.
+
+The Failed Transaction email fails to get sent for a few days before its absence is noticed. Due to poor logging there is no easy way to find the failed records. Instead 100% of all transactions have to be investigated to find the failures, resulting in a significantly larger task.
+
+### Scenario #2
+
+An application to process credit card payments at a conference is created. As part of its creation, a detailed log file is created to track the transactions and stored on a shared network drive. The logging includes records of the credit card details. A user browsing the network drive discovers this file and is able to obtain all of the credit card data.
I know that this was part of current available version, but should we move
this risk of having too verbose logs to LCNC-SEC-08?
------------------------------
In content/2022/en/LCNC-SEC-05-Security-Misconfiguration.md
<#56 (comment)>
:
> @@ -11,6 +11,8 @@ title: "LCNC-SEC-05: Security Misconfiguration"
| --- | --- | --- | --- |
| 3 | 2 | 3 | 3 |
+In building a solution, many choices have to be made that can impact security. This risk is a bit of a “catch-all” where a user makes choices to settings that create risk. They can range from how/where sensitive data is stored, encryption settings, and more.
I'd like to offer a slightly different perspective: Platforms offer a wide
variety of features, each with its own balance of productivity vs risk.
It's up to users to make the right choices when combining those features.
—
Reply to this email directly, view it on GitHub
<#56 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A6LUF3R2ZLJY44L6XHVREPTXED32RANCNFSM6AAAAAAXOK424A>
.
You are receiving this because you were mentioned.Message ID:
<OWASP/www-project-top-10-low-code-no-code-security-risks/pull/56/review/1408947392
@github.com>
|
Thank you John. I just had a very similar conversation about rewriting the risks in a language that speaks to executives, rather than engineers. I feel like there's an opportunity for us to cover the same issues in many different levels for each target audience: executives, security engineers and business users. We do need to keep in mind that the primary audience for OWASP is security profesionals, so that content should be easily available. I expect they will be the ones who point business users to our project. As a next step, I suggest we go through the following to merge your contributions into the project:
I'll reach out on a separate thread regarding categories. |
Mostly grammatical changes
Update LCNC-SEC-01-Account-Impersonation.md
Update LCNC-SEC-02-Authorization-Misuse.md
Update LCNC-SEC-03-Data-Leakage-and-Unexpected-Consequences.md
Update LCNC-SEC-04-Authentication-and-Secure-Communication-Failures.md
Update LCNC-SEC-05-Security-Misconfiguration.md
Update LCNC-SEC-07-Vulnerable-and-Untrusted-Components.md
Update LCNC-SEC-09-Asset-Management-Failures.md
Add business language and scenarios
|
Hi @nekosoft @johndtgroup can I merge? 🚀 |
You sure can! Thank you :) |
PR Checklist
Purpose
See issue: #48
Description
This PR proposes the following:
Help Required for Review:
Authored by @johndtgroup and @nekosoft