1. Byte: An 8-bit signed two's complement integer.
   • Range: -128 to 127 (inclusive)
   • Storage: 1 byte
2. Short: A 16-bit signed two's complement integer.
   • Range: -32,768 to 32,767 (inclusive)
   • Storage: 2 bytes
3. Int: A 32-bit signed two's complement integer.
   • Range -2³¹ to 2³¹-1
   • Storage: 4 bytes
4. Long: A 64-bit signed two's complement integer.
   • Range: -2⁶³ to 2⁶³-1
   • Storage: 8 bytes
5. Float: A single-precision 32-bit IEEE 754 floating point.
   • Range: approximately (+/-) 3.40282347E+38F (6-7 sig)
   • Storage: 4 bytes
6. Double: A double-precision 64-bit IEEE 754 floating point.
   • Range: approximately: (+/-) 1.79769313486231570E+308 (15 sig)
   • Storage: 8 bytes
7. Char: A single 16-bit Unicode character
   • Range: 0 to 65,535 (inclusive)
   • Storage: 2 bytes
8. Boolean: This represents one bit of information, but its 'size' isn't precisely defined.
   • Range: true or false
   • Storage: Not precisely defined, often 1 byte for practicality but it can vary.

As you can see once we exceed the max/min for a datatype it then wraps around to the other end of the range. This can cause a lot of issues when writing code. Especially since there are issues maintaining data when changing between types. Since and Int is 4 bytes and a Char is 2 bytes when the following code runs, only 2 bytes are kept: 32

1010000110000000000100000 = 21168160 (MyNumber)

000100000 = 32 (MyChar)

• Perimeter security includes firewalls, WAFs, security information and event management (SIEM) products, etc. to protect an internal network from the malicious network traffic coming in and out.
• The biggest challenge in security over the past two decades has been the dissolution of the perimeter.
• As the cloud becomes more utilised, perimeter security will become less effective.
• Due to more advanced threats, we must make sure that our data, software, and networks are protected by more than just perimeter security measures.

• Instead of securing broken software against attack, why don't we just build software that's not broken in the first place?
• It is all about building security into the software and it is being developed throughout the SDLC.
• The Building Security in Maturity Model (BSIMM) is working to find out what measures are companies taking to ensure their data is safe by measuring software security initiatives of 78 organisations throughout 12 industries.
• While perimeter security acts as an organisation's first line of defence, it's not the one true answer to security.

• Unlike dynamic analysis, the promise of static analysis is to identify common coding problems (implementation bugs) automatically, before a problem is released.
• If a rule hasn't yet been written in the tool, it will never find that problem.
• The best a code review can uncover is about 50% of security vulnerabilities.
• The other 50% are vulnerabilities due to architectural/design flaws which are very difficult to identify from code.
• Tools have limited impact:
  • Black box security testing only works for Web applications because HTTP protocol is stateless and simple.
  • Code review tools only look for bugs in code written in certain programming languages.
  • Code review tools are unable to identify architectural flaws.

• Tools also suffer from:
• False positives: tools report bugs that the program doesn't actually contain. The can be frustrating to analysts/developers who are responsible for sorting/fixing them.
• False negatives: the program contains bugs that the tool doesn't report. They are more dangerous because they lead to a false sense of security.
• Software security should leverage tools and automation whenever possible for efficiency and scale, but tools alone are not a sufficient stand-alone practice for achieving secure software.
• A comprehensive approach of tools and architectural review conducted by humans (security experts) is the only approach to achieving the most secure software.

• Penetration testing is the most frequently and commonly applied of all software security practices. But, this isn't necessarily a good thing.
• It could be done by “reformed hackers” who could be malicious and hide some of the bugs (findings) they found during the penetration testing.
• Security issues often involve unexpected misuse of an application discovered by an attacker.
• It's much more difficult to show whether or not a system is secure enough under malicious attack. How many tests do we need to do before giving up and declaring “secure enough”?

• Software security ≠ security software, Adding a crypto library or a security feature to an application, is not the same thing as making that application secure.
• Remember, security is a system property, not a thing.
• Cryptography can te a useful tool when it comes to securing data and communications but it's no silver bullet.
• If a SQL injection is found in an application that talks to an encrypted database, do you think encrypted data or plain text data will be returned?
• Not only is the math difficult, applied cryptography is filled with sneaky pitfalls that are very difficult to get right.

• Cryptography can't find or eliminate bugs and flaws.
• Cryptography can't train your developers how to write secure code.
• Applied Cryptography is designed to protect data, not the application that processes data.
• Thea most cornmon security feature in a developer's mind is cryptography. Security is not a feature nor a function.
• Software security is not simply integrating security features into the code, it is about integrating security practices into the way we build software.

• The division of design flaws and bugs is about 50/50; both need to be fixed.
• Code reviews and static analysis unlikely will be able to find and fix flaws. Flaws must be found and resolved by experienced people by using threat modelling and architecture analysis techniques.
• Finding bugs is great, but unless we fix what we find, security doesn't improve.
• It is important to train developers not to introduce new bugs every day.
• Remember, bugs are only half of the equation. Make sure to also focus attention on flaws occurring at the design level.

• Solving software security is not as easy as picking only one group (developers, compliance people, or security people) to hang the security problem on.
• Software security is the responsibility of everyone but it must be coordinated by a central seftware security group (SSG).
• The SSG should regroup:
  • Software pecpie with deep development know-how.
  • Security peopie with strong architectural knowledge.
  • People who can interact with the business.
• It is important to arm developers with software security know-how, but it is important also to check code for bugs, check design for flaws and check systems for security holes.
• Developers don't write all the code we deploy.

• Focusing all of the attention on apps that carried the most risk is over these days. Today it's about securing the entire portfolio - the overall attack surface.
• Risk management decisions (usually by CISO) is a careful balance between security and business functionality.
• Recommendations:
  • Leave no code without security control.
  • Tighten security controls between low and high risk assets to the extent possible without moving the high risks down the prioritisation list.
  • Create a specific testing schedule for internal low-risk applications.
• It is important to cover their entire software portfolio - both the high-risk and the low-risk apps must be taken into consideration.