2.3 - Application Development, Deployment, and Automation Concepts

Question 1

Development to Production

Answer 1

• Deployment
• Can’t just copy and paste
• Many checks that must happen first
• Might need to patch (do you test them? how long do you wait?)
• Need to closely monitor these steps

Question 2

Sandboxing

Answer 2

• Isolated testing environment
• No connection the real world or production system
• A technological safe space that developers can use for testing, won’t affect anyone but other ppl using sandbox
• Sandbox can be used over and over (Incremental development)

Question 3

Development

Answer 3

• Programmer writes the code in a secure environment and begins testing different functions
• Will continue to add on

Question 4

Test Environment

Answer 4

• More formal than development, but still part of the development stage
• All the pieces are put together
• Does it work?
• functional tests

Question 5

QA

Answer 5

• Quality Assurance
• Verifies features are working as expected
• Outside scope of development team
• this group tests new features
• Verifies that old errors don’t reappear
• Once developers think application is working as expected, they can push to QA

Question 6

Staging

Answer 6

• Chance to test application in real world environment
• Works and feels like production
• Might use a copy of production data
• Almost ready to roll it out
• Run performance tests
• Test usability and features

Question 7

Production

Answer 7

• Application is live
• Rolled out to the user community
• May need to train users
• Challenging step since it affects users
• Logistical challengers (maybe new servers, etc. that may impact availablity)

Question 8

Secure baselines

Answer 8

• The security of an application environment should be well defined
• All application instances must follow this baseline
• Firewall settings, patch levels, OS file versions
• Want to make sure they’re always up to date
• Run Integrity management checks

Question 9

Integrity Measurement checks

Answer 9

• Within the scope of the secure baseline
• Should be performed often, check against well-documented baselines
• Failure (if not matching) requires an immediate correction

Question 10

Provisioning

Answer 10

• Process of making something available
• Ex: provisioning an application, probably will deploy a web server, database server, middleware server, user workstations configurations, certificate updates, etc.
• Deploying an application is a deployment instance b/c it includes all these things
• Also includes Application software security (Ex: OS, application)
• Network security (Secure VLAN, internal / external acces)
• Software deployed to workstations might also want to check executables for malicious code

Question 11

Scalability

Answer 11

• The ability to increase the workload in a given infrastructure
• When you first create an application instance, you build it to handle everything up to a certain load
• Ex: application instance can 100K transactions per second then everything in this will be able to handle this load

Question 12

Elasticity

Answer 12

• Increase / decrease available resources as the workload changes
• Ex: deploy multiple application instances to handle 500K transactions per second, if initial load of 100K is not sufficient
• Ex: if an application becomes popular
• Ex: deploying more or less application instances
• Ex: If you know application scalability can handle 100K instances per second and we nee to now handle 500K per second, we know we will need 5 instances
• (Same thing in reverse to decrease instances, which affects the total number of transactions per second an application can handle)

Question 13

Orchestration

Answer 13

• key to cloud computing b/c you can automate the provisioning / deprovisioning of applications
• Entire application instances can be instantly provisioned (deployed) (Ex: all servers, networks, switches, firewalls, and policies)
• Services appear and disappear automatically ,or at the push of a button
• Can orchestrate WHERE the instances are provisioned (aka follow the Sun, provision when it’s day in Europe, and then deprovision and provision the US)
• Automation will also apply to all security components as well

Question 14

Deprovisioning

Answer 14

• Dismantling and removing an application instance
• Not just turning off application, but removing any remnants of application running in your environment
• Don’t want to leave open holes (or close important ones)
• Have to deprovision all security components as well (ex: not only removing firewalls, etc, but may have to remove individual rules in the firewall)
• If the application is gone, so is the access
• What happens to Data? It could have been copied somewhere else secure or everything is removed. (Don’t leave data around)

Question 15

Secure Coding Concepts

Answer 15

• Balancing act b/n time it takes to create app and quality of final product
• Want app to do everything we need but also be secure
• Testing (QA) takes a lot of time
• Vulnerabilities will eventually be found and this will need to be patched

Question 16

Stored Procedures

Answer 16

• One way to make application more secure
• Make SP for DB calls
• Attacker cannot modify the SP parameters (like they could if it there was no SP)
• You can only run or not run procedure
• Developer would need to create a SP for every DB call in the application, making the overall application much more secure

Question 17

Obfuscation

Answer 17

• Making something normally understandable and making it very difficult to understand
• aka camouflage
• Developers take code they’ve written and make it very difficult to read (but computer still understands). both sets of code behave identically
• Helps prevent the search for security holes, makes it more difficult for attackers to figure out what’s happening (but not impossible)

Question 18

Code reuse

Answer 18

• Code reuse can intorduce security issues
• Developers tempted b/c it saves time to copy and paste
• If old code has a security vulnerability, and it’s copied to other apps, it spreads

Question 19

Dead code

Answer 19

• Code that no longer performs a function
• Ex: Calculations are made, code executed, results tallied and results aren’t used anywhere else in the application
• All code is an opportunity for a security problem, make sure your code is alive as possible

Question 20

Input validation

Answer 20

• What is the expected input? validate actual vs expected
• Attackers will look for places where the input is not being properly validated
• Ex: if application is asking for a zip code, or uploading a file, all of this needs to be validated
• Should display a message to the user or logic in the application if it can fix input

Question 21

Normalization

Answer 21

• Check and correct all input
• Ex: a zip code should be X characters
• Fix any data with improper input

Question 22

Fuzzer

Answer 22

• Inserting massive amounts of random data, or fuzz, into source code and observing the outcomes.
• Attackers will use fuzzers to try to get around input validation

Question 23

Validation points

Answer 23

• Server side Validation (usually considered safer alternative)
• Client-side
• Both a lot of apps use both

Question 24

Server- side validation

Answer 24

• All checks occur on the server
• Data sent into server and code on server is validating data
• Prevents users from changing data before it gets to the server in hopes of getting around the validation process
• Helps protect against malicious users
• Attackers may not even be using your interface

Question 25

Client-side validation

Answer 25

• Validate the data on the client’s machine and then determine if it’s appropriate to send to the server
• The end-user’s app makes the validation decisions
• Can filter legitimate input from genuine users
• May provide additional speed to the user, all checks made on local machine

Question 26

Memory Management

Answer 26

• Developer concerned about memory use, where are variable stored, are they all available to the application
• Security concern b/c users will input data and these are stored in memory
• Attackers can attempt to circumvent your code and put own data into the memory of your computer
• Ex: A buffer overflow attack exploits memory issues

Question 27

Buffer Overflow

Answer 27

• Attackers may try to flood your site with too much data
• Might cause app to crash or provide user with additional access
• Huge security risk
• Sometimes it’s better to build your own functions (instead of relying on 3rd party libraries (built in functions) which may be insecure)
• use best practices when designing your code
• Make sure your data matches your buffer sizes

Question 28

Third-Party Libraries

Answer 28

• can speed up the development process, b/c someone has already written a function you need
• Security risk - written by someone else, so you don’t know if there are vulnerabilities
• To combat - if you’re going to use a 3rd party library, do your research, know how secure it is

Question 29

SDK

Answer 29

• Software development kit
• Extends the functionality of the programming language
• can speed along the development process
• Security risk - written by someone else, so you don’t know if there are vulnerabilities
• To combat - if you’re going to use a 3rd party SDK, do your research, know how secure it is

Question 30

Data Exposure

Answer 30

• A lot of sensitive data you put in an application
• Need to make sure you’re encrypting data
• If sending across network, need to send it encrypted
• If displaying on a screen, may want to hide some of the data
• All input / output process are important - check them all for data exposure

Question 31

Version Control

Answer 31

• Create a file, make a change, they can keep track of different versions
• Commonly used in application dev, OS, cloud-based file storage
• Useful for security, compare versions across time (identify modifications to important files)
• Saving versioning can be a powerful security tool, but it can also be a security risk (a third party could gain access to sensitive information)

Question 32

Exploiting an application

Answer 32

• Attackers often exploit application vulnerabilities (once you exploit one binary, you can exploit them all)
• To combat: constant Patch updates for OS and applications (update everyone’s system)
• A unique way to combat: Software Diversity Run unique binaries on all computers even though software is the same (ex: ppl running Windows 10, but everyone’s binary is slightly different)

Question 33

Software Diversity

Answer 33

Software Diversity Run unique binaries on all computers even though software is the same (ex: ppl running Windows 10, but everyone’s binary is slightly different)
- Change where the paths go during the compilation process (functionality remains the same) means the final binary will be different every time you compile
- If an attacker finds an exploit and attacks an application they may not be able to reuse it on someone else’s computer (only successful with a fraction of the users)
- It is extra work to have diversity you could minimize attack surface (also limits attack potential to only one type of binary file)
- One way to combat application exploits

Question 34

Automation around Deployment

Answer 34

• Many problems can be predicted and you can set up automated responses
• Ex: if you know that if storage filles up, your app will fail, may want to continuously monitor that drive to make sure it doesn’t get too full, if it’s getting too full, can then react (delete old files, etc to free up space)
• very important for cloud (b/c may be automatically provisioning / deprovisioning)

Question 35

CI

Answer 35

• Continuous Integration
• Code is constantly written
• Merged into the central repository many times a day
• Could open potential for security problems
• Automation is helpful for this b/c basic security checks can happen during development (verify new code against these checks)
• Documented security baselines as the bare minimum
• After software comes out of development process there may be larger scale security checks during the testing phase

Question 36

CD - delivery

Answer 36

• Continuous Delivery
• Automated testing during the testing process
• Automate the release process
• Click a button and deploy the application

Question 37

CD - deployment

Answer 37

• Continuous Deployment
• Automatically deploy to production
• No human integration or manual checks (entire testing / deployment process is automated)
• Even more automation
• If a problem arises the application won’t be pushed but if all checks pass, it automatically deploys to production