Read the original article: Application Security for builders and creators
Meet Alice and Bob
Alice and Bob work for an exciting data analytics startup that is disrupting the healthcare tech space. You might have heard their names as they are well known in the security industry for building apps that are secure by design. As creators, they also enjoy rapidly prototyping ideas into functional apps that demonstrate innovative thoughts and potential solution to customer problems.
“Let’s build a vaccine passport app!” declared Alice during one of those recurring zoom meetings.
“You know what I’ve been thinking about it as well. Let’s do it!” said Bob as he hurriedly unmuted himself.
“We can involve Claire as well, our new DevSecOps person, since it will be best to get security built into the product from the start,” said Alice.
Bob asked, “Won’t that slow us down Alice? Can we build the app first to see if there any downloads from the AppStore and then implement security features next month?”.
Before Alice could respond, Bob quickly replied, “I’m just joking! Of course, safety and privacy of our users are more important not just speed and time to launch”.
Claire now joins the Zoom meeting.
Chat up with the devs
“OMG, that will be a super cool app!” said Claire before Alice and Bob could even describe their app idea. The boring Zoom meeting suddenly became a design discussion between the devs (Alice and Bob) and the security person (Claire). Claire starts by asking for some basic information about the app and takes notes for future reference.
- Team: Who are the developers, DevOps and Product Owners?
- User stories: Are there any existing user stories providing an overview of the app?
- Tech: What is the application and cloud technology stack?
- Architecture: Are there any diagrams even the back of the napkin ones?
Gathering information through formal and informal discussions with devs is an essential skill to succeed in an AppSec or DevSecOps and even in a cybersecurity role. A good knowledge about the application helps build a relationship with not just the dev team but also with the security testing tools (including the vendor). A well configured static analysis-based security tool would help with both developer productivity and application security.
Bootstrap the app
Our vaccine passport app is going to have a go micro-services backend, and a React front-end Single Page App (SPA). This will be followed by a native mobile app for Android and iOS built using React Native framework.
Having read my blog on DevSecOps with GitHub, Claire suggests the team to integrate ShiftLeft NG SAST with their GitHub repo’s workflow from the start. Alice and Bob are naturally sceptical. After all, the app they are thinking is new and therefore any automated security analysis is bound to create false positives and require hours of triaging right?
With this feedback from the devs, Claire plans her homework. She goes through the documentation pages for go and react on ShiftLeft over the weekend. She decides to customize the default analyze command used by ShiftLeft by adding some custom tags.
# Default command
sl analyze --js --app passport-fe .
sl analyze --go --app passport-backend .
# Claire’s command
sl analyze --js --app passport-fe
--tag app.group=alice-team \
--tag stage=poc \
--tag threat_model_id=page-100 \
--tag classification=sensitive \
--tag branch=${GITHUB_REF} \
.
sl analyze --go --app passport-backend \
--tag app.group=alice-team \
--tag stage=poc \
--tag threat_model_id=page-101 \
--tag classification=sensitive \
--tag branch=${GITHUB_REF} \
.
The additional custom tags added by Claire are based on the notes from the information gathering session with the devs. These tags can be any key-value pairs and are completely optional. In this particular example the following tags are used.
- stage=poc — This would help decide on the business criticality of this app if there is any incident that might cause downtime
- threat_model_id=page-100 — This is the id for the wiki pages where the notes and the architecture diagrams shared by the devs are kept
- classification=sensitive — Even though the app is at a poc stage, the users will be sharing their medical, vaccine and personal information so the data is sensitive. With this tag, Claire can check and ensure if the app continues to have safeguards to prevent sensitive data from getting leaked from the cloud or to the logs
- branch=${GITHUB_REF} — By assigning the Git branch as the branch name, separate reports can be maintained for each branch and its Pull Request.
With this GitHub workflow including ShiftLeft NG SAST in place, the team decides to meet up over zoom to discuss the data that will be collected and stored by the app.
Gather data dictionary
Every app uses different terms and variable names in the code to represent data. A variable called “Customer” or “Patient” can potentially contain sensitive information that should be kept safe and private whereas a variable called “tmpCounter” is usually safe.
The vaccination app would collect the following data from the users:
- Customer: Personal information such as their names, address and location
- Vaccination data: The date, location and the type of the vaccine the customer received. A photo of the vaccine and a copy of the confirmation letter would also be uploaded and stored via the app
The backend would support the following functionality via its API:
- Store and retrieve customer information
- Upload photos and evidence of vaccine to an AWS s3 bucket
- Generate confirmation and unique reference for a trusted authority to query and confirm the vaccination status
The team agrees that the data would always be encrypted both at rest and in transit. Further, they would never log any sensitive information to the log files but maintain a generic audit log to track the usage of all API calls that can retrieve sensitive information. In summary, always encrypt, don’t log but audit.
Configure NG SAST data dictionary
Claire knows quite well that both Alice and Bob would stick to their words and always use encryption for data and obfuscation for logs. But regulators and auditors unfortunately require evidence of compliance and cannot just take someone’s word as assurances. Even the best devs sometimes do make a mistake, so it is best to configure a tool to track the usage of sensitive data for peace of mind.
Having come across the documentation page for customizing the sensitive data dictionary, Claire learns that while ShiftLeft has a broad collection of terms in the default dictionary it won’t have terms such as covid or vaccine and so on. She therefore decides to try adding some app-specific terms to the default dictionary using a policy file.
IMPORT io.shiftleft/defaultdict
DATA highlySensitive = VAR vaccine, covid, clinic, dosage
DATA pii = VAR vaccine photo, evidence image, clinic location, vaccination date
The above snippet is saved in a file called passport.policy. By using the sl policy command Claire adds this new policy that includes new data dictionary to ShiftLeft.
sl policy push passportrules passport.policy
sl policy assignment set --project passport-backend <ShiftLeft Org Id>/passportrules:latest
Dev-Test-Iterate
With the ShiftLeft integration along with the right data dictionary in place, NG SAST analysis would automatically run whenever Alice or Bob create a Pull Request. Initially, they decide not to use ShiftLeft as a Required Status Check since they do not want their merges to be blocked by a SAST tool yet. The good news is that NG SAST is designed for spotting realistic security defects and business logic flaws thanks to our code property graph, so it doesn’t cry wolf for everything.
Few weeks pass with both the frontend app and the microservices API gaining features rapidly. Then the unexpected happens – ShiftLeft NG SAST reports few security findings and the team gets quite anxious. They decide to meet over zoom to discuss the security findings the next day.
To be continued …
Application Security for builders and creators was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
The post Application Security for builders and creators appeared first on Security Boulevard.
Read the original article: Application Security for builders and creators