The document outlines methodologies for enhancing cyber defense through software walkthroughs, code reviews, and pair programming, emphasizing the importance of scrutinizing both hardware and software to prevent cyber threats. It discusses formal and informal approaches to software inspections, detailing best practices for conducting reviews and identifying potential defects in code. Additionally, it highlights the necessity of local industry and academic collaboration to reduce foreign dependency in cyber defense capabilities.

1. Software Walkthrough and
Screening
Capability Building for Cyber Defense
Dr. Fahim Arif
(PhD in Software Engineering)
Director R&D
Senior Member IEEE
MCS (NUST)

2. The life of a cyber threat
Let us what is a cyber threat

3. Premise
• Today’s need – modern equipment/ gadgets
• Hardware and software
• Foreign dependency
National Level
• Indigenization ------ desire and need
• Local industry/ R&D ?????????????????????
• Academia
• Manpower/ HR

7. What to do?
• Screening of Hw and Sw
• Software and code walkthrough
• Back doors
• Channels
• Malwares
• Hidden traps

8. How to do it?
• Software or Code Walkthroughs
• Code Reviews
• Software Inspections
• Paired Programming
• Alternative Approaches
9
Generally, not
technically

9. DEFINITION
In software engineering, a walkthrough is a form of software peer
review "in which a designer or programmer leads members of the
development team and other interested parties go through a software
product, and the participants ask questions and make comments about
possible errors, violation of development standards, and other
problems.
[IEEE Std. 1028-1997, IEEE Standard for Software Reviews, clause 3.8]
Software Walkthroughs

10. Software Walkthroughs
• Methodology
• A walkthrough is an informal way of presenting a technical document
in a meeting.
• An author or coordinator runs the walkthrough: calling the meeting, inviting the
reviewers, soliciting comments and ensuring that everyone present understands
the work product.
• Walkthroughs are used when the author of a work product needs to take into
account the perspective of someone who does not have the technical expertise to
review the document.
• After the meeting, the author should follow up with individual attendees who
may have had additional information or insights. The document should then be
corrected to reflect any issues that were raised.
13

11. • Verify that everyone is present for this activity. This can include
users, stakeholders, engineering leads, managers and others
• Ensure that everyone present understands the purpose of the
walkthrough and how the material is to be presented.
• Describe each section of the material to be covered by the
walkthrough.
• Present the material in each section, ensure that everyone
present understands the material.
• Lead a discussion to identify any missing sections or material.
• Document all issues that are raised by walkthrough attendees.
14Guidelines for a Successful Walkthrough

12. • For more information about Walkthroughs:
• http://www.jodypaul.com/SWE/WT/walkthroughs.html#types
15
Software Walkthroughs

13. Code Review
• A code review is a special kind of inspection in which the team
examines a sample of code and fixes any defects in it.
• In a code review, a defect is a block of code which does not properly
implement its requirements, which does not function as the programmer
intended, or which is not incorrect but could be improved
• For example, it could be made more readable or its performance could be
improved
16

14. Code Review
• It’s important to review the code which is most likely to have defects. This will
generally be the most complex, tricky or involved code.
• Good candidates for code review include:
• A portion of the software that only one person has the expertise to maintain
• Code that implements a highly abstract or tricky algorithm
• An object, library or API that is particularly difficult to work with
• Code written by someone who is inexperienced or has not written that kind of code
before, or written in an unfamiliar language
• Code which employs a new programming technique
• An area of the code that will be especially catastrophic if there are defects
17

15. Code Review
• Meetings are not the answer, why? http://vimeo.com/29531712
• Can’t see the new code working.
• Only covers other important code, which can leave mistakes or errors in other code.
• Hard to track changes in larger reviews.
• Using tools allows:
• Gathering changed files over multiple iterations of changes.
• No meetings required the review can be done at any time by any number of
reviewers.
• All conversations, changes, and defects are tracked.
• Requires all participants to verify the code before the review is completed.
18

16. Code Review 19

17. Essential elements of
a formal code review
• Identify problems:
• Find problems with the software such as missing items, mistakes, etc.
• Follow rules:
• Amount of code to be reviewed, how much time will be spent, etc.
• Prepare:
• Each participant should prepare in order to contribute to the review.
• Write a report:
• Summarize the results of the review, make report available to the
development team.

18. Formal code inspections
• Code presenter is not the author of the code.
• The other participants are the inspectors.
• There is a moderator to assure that the rules are followed and the
meeting runs smoothly.
• After the inspection a report is composed. The programmer then
makes changes and a re-inspection occurs, if necessary.
• Formal code inspections are effective at finding bugs in code and
designs and are gaining in popularity.

19. Pair Programming
• Pair programming is a technique in which two programmers work
simultaneously at a single computer and continuously review each
others’ work.
• Although many programmers were introduced to pair programming
as a part of Extreme Programming, it is a practice that can be
valuable in any development environment.
• Pair programming improves the organization by ensuring that at
least two programmers are able to maintain any piece of the
software.
22

20. Pair Programming (pros and cons)
• In pair programming, two programmers sit at one computer to write code.
Generally, one programmer will take control and write code, while the other
watches and advises.
• Some teams have found that pair programming works best for them if the pairs are
constantly rotated; this helps diffuse the shared knowledge throughout the organization.
Others prefer to pair a more junior person with a more senior for knowledge sharing.
• The project manager should not try to force pair programming on the team; it helps
to introduce the change slowly, and where it will meet the least resistance.
• It is difficult to implement pair programming in an organization where the programmers
do not share the same nine-to-five (or ten-to-six) work schedule.
• Some people do not work well in pairs, and some pairs do not work well together.
23

21. Pair Programming
• 2x4 Pair Programming Rotation
• http://www.youtube.com/watch?v=TzUNGOVrhWs
24

22. Alternative Approaches
• Automated Reviews:
• A review conducted by a computer. (Tool-assisted)
• Reduced manual cost of code reviews
• Fast, consistent, and repeatable
• Removes emotion from the reviews: pride, ego, and ownership need to be
constantly recognized when conducting a review
• In some cases you have tools that allow for real-time reviews, such as the
Eclipse plug-in CodePro Analytix or Resharper for C#. These tools perform an
examination of the code as it is being written.
25
Automated file-
gathering,
combined display,
automated metrics
collection, etc

23. Recent Examples
Jan 2018
• Massive CPU (Intel) flaws get a name: Meltdown and Spectre
• both potentially allow hackers to steal personal data from computers,
including mobile devices and cloud servers, without leaving a trace
Feb 2018
• Cisco has issued patches for the vulnerability, which could be up
to seven years old.
• The vulnerability received a Common Vulnerability Scoring System base
score of 10.0, the highest possible. It was first discovered by Cedric
Halbronn, a researcher with NCC Group

24. Read the advisories and updates
• Juniper
• https://kb.juniper.net/InfoCenter/index?page=content&channel=SECURITY_ADVISORIES
• CISCO
• https://tools.cisco.com/security/center/publicationListing.x
• Huawei
• https://www.huawei.com/en/rss-feeds/psirt

25. Technical Portion

27. Code review checklist:
Data reference errors
• Is an un-initialized variable referenced?
• Are array subscripts integer values and are they within the array’s
bounds?
• Are there off-by-one errors in indexing operations or references to
arrays?
• Is a variable used where a constant would work better?
• Is a variable assigned a value that’s of a different type than the
variable?
• Is memory allocated for referenced pointers?
• Are data structures that are referenced in different functions
defined identically?

28. Code review checklist:
Data declaration errors
• Are the variables assigned he correct length, type, storage class?
• E.g. should a variable be declared a string instead of an array of characters?
• If a variable is initialized at its declaration, is it properly
initialized and consistent with its type?
• Are there any variable with similar names?
• Are there any variables declared that are never referenced or just
referenced once (should be a constant)?
• Are all variables explicitly declared within a specific module?

29. Code review checklist:
Computation errors
• Do any calculations that use variables have different data types?
• E.g., add a floating-point number to an integer
• Do any calculations that use variables have the same data type but are different
size?
• E.g., add a long integer to a short integer
• Are the compiler’s conversion rules for variables of inconsistent type or size
understood?
• Is overflow or underflow in the middle of a numeric calculation possible?
• Is it ever possible for a divisor/modulus to be 0?
• Can a variable’s value go outside its meaningful range?
• E.g., can a probability be less than 0% or greater than 100%?
• Are parentheses needed to clarify operator presence rules?

30. Code review checklist:
Comparison errors
• Are the comparisons correct?
• E.g., < instead of <=
• Are there comparisons between floating-point values?
• E.g., is 1.0000001 close enough to 1.0000002 to be equal?
• Are the operands of a Boolean operator Boolean?
• E.g., in C 0 is false and non-0 is true

31. Code review checklist:
Control flow errors
• Do the loops terminate? If not, is that by design?
• Does every switch statement have a default clause?
• Are there switch statements nested in loops?
• E.g., careful because break statements in switch statements will not exit
the loop … but break statements not in switch statements will exit the loop.
• Is it possible that a loop never executes? If it acceptable if it
doesn’t?
• Does the compiler support short-circuiting in expression evaluation?

32. Code review checklist:
Subroutine parameter errors
• If constants are passed to the subroutine as arguments are they
accidentally changed in the subroutine?
• Do the units of each parameter match the units of each
corresponding argument?
• E.g., English versus metric
• This is especially pertinent for SOA components
• Do the types and sizes of the parameters received by a subroutine
match those sent by the calling code?

33. Code review checklist:
Input/Output errors
• If the file or peripheral is not ready, is that error condition handled?
• Does the software handle the situation of the external device being
disconnected?
• Have all error messages been checked for correctness,
appropriateness, grammar, and spelling?
• Are all exceptions handled by some part of the code?
• Does the software adhere to the specified format of the date being
read from or written to the external device?

34. Code review checklist:
Other checks
• Does your code pass the lint test?
• E.g., How about gcc compiler warnings?
• Is your code portable to other OS platforms?
• Does the code handle ASCII and Unicode?
• How about internationalization issues?
• Does your code rely on deprecated APIs?
• Will your code port to architectures with different byte orderings?
• E.g., little (increasing numeric significance with increasing memory addresses) versus big
(the opposite of little) endian?

35. • Code Review Checklist
• Clarity
• Is the code clear and easy to understand?
• Did the programmer unnecessarily obfuscate any part of it?
• Can the code be refactored to make it clearer?
• Maintainability
• Will other programmers be able to maintain this code?
• Is it well commented and documented properly?
• Accuracy
• Does the code accomplish what it is meant to do?
• If an algorithm is being implemented, is it implemented correctly?
• Readability and Robustness
• Is the code fault-tolerant? Is the code error-tolerant?
• Will it handle abnormal conditions or malformed input?
• Does it fail gracefully if it encounters an unexpended condition?
• Security
• Is the code vulnerable to unauthorized access, malicious use, or modification?
• Scalability
• Could the code be a bottleneck that prevents the system from growing to accommodate
increase load, data, users, or input?
• Reusability
• Could this code be reused in other applications?
• Can it be made more general?
• Efficiency
• Does the code make efficient use if memory, CPU cycles, bandwidth, or other system
resources?
• Can it be optimized?
41