CSS321_JoshuaGardner_IP5

1 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A CSS321: Software Assurance Software Assurance Guideline – T-Mobile U.S.A. Individual Project – Week 5 Joshua Gardner November 5 th , 2023

2 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A Table of Contents Unit 1: Project Outline ............................................................................................................. 3 Company Description ....................................................................................................................... 3 Applications Provided ....................................................................................................................... 3 Development Methods ...................................................................................................................... 4 Unit 1: Security in the Development Life Cycle ......................................................................... 5 SDLC ................................................................................................................................................. 5 Security Development Components .................................................................................................. 6 Unit 2: Software Assurance Techniques .................................................................................... 7 Analysis ............................................................................................................................................. 7 Guidelines ........................................................................................................................................ 10 Unit 3: Security in Nontraditional Development Models ......................................................... 11 Identifying Non-Traditional Security Model ...................................................................................... 11 Non-Traditional Development Process .............................................................................................. 12 Non-Traditional Software Development Policies & Processes ........................................................... 14 Section 4: Security Static Analysis .......................................................................................... 16 Application Design Layout ................................................................................................................ 16 Component Diagram ........................................................................................................................ 17 Major Components .......................................................................................................................... 17 C++ Code Samples ............................................................................................................................ 19 Security Static-Analysis Tools & Guidelines ....................................................................................... 19 Unit 5: Software Assurance Policies and Processes ............................................................... 21 Software Assurance Training Plan ..................................................................................................... 21 Software Assurance Metrics ............................................................................................................. 22 Security Team Roles & Responsibilities ............................................................................................ 23 Resources .............................................................................................................................. 24

4 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A T-Mobile Home Internet. Additionally, they also have an online web interface for their account management and an internal desktop application for customer account management that also uses a database to pull all the customers information. Development Methods While T-Mobile is large organization, it is comprised of a multitude of different organizations within the company. In this guideline we will be specifically looking at their technology team. Currently, T-Mobiles technology team recently saw a new change in leadership as John Saw took over as Chief Technology Officer in April of 2023. The company currently employs a hierarchical structure when it comes to reporting. Within the technology field it is divided into subsets with some teams specializing in UX, mobile application, and internal software teams. While T-Mobile does hire remote workers for their tech space, they tend to prefer to hire employees who are located near a customer experience center or headquarters. As part of their development T-Mobile has a set of internal systems used to develop their programs for their internal care teams as well as generalized operating system platforms to produce their application-based platforms. As a direct employee for T-Mobile when it comes to testing their internal software, there are specific employees throughout multiple facets of the business that specifically pilot these programs.

5 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A Unit 1: Security in the Development Life Cycle SDLC The purpose of this section is to review the software development life cycle (SDLC) within T-Mobile. I can help provide a breakdown of each of the major components of the company’s SDLC as I am currently employed within their technology team and therefore have firsthand knowledge of the software process. In addition to providing a brief rundown of the major phases within the SDLC, this section will also discuss components of the security development model and how they pertain to each phase of the SDLC model. Lastly, this section will also discuss how the security model is applied within each phase of the SDLC cycle. As mentioned in the first section of this repot, T-Mobile publishes applications that are used on an internal basis only, as well as applications and web platforms that are used externally on the customer facing side. The importance in using an SDLC is essential as it provides the software team with a way to develop, test, and publish their software. While the SDLC follows a general format, dependent on the organization you’re working for, there may be slight differences (Softwaretestinghelp, 2023). In the case of T-Mobile, our organization has a total of six distinct phases. Each project begins with the Requirements Gathering / Planning phases. This is followed by the design phase, then the coding phase (my current role), and then dependent on the team lead there is the deployment phase and lastly the maintenance phase. Dependent on the team in some instances the deployment and maintenance phase are grouped together. In the first phase, the technical leadership team reviews information obtained from feedback both internal and external teams which is then used to develop and idea for a software product. After a need for a service has been identified, a member of our business support team, will meet with a tech lead to discuss what needs to be built and how it will improve the business

7 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A the coding phase, a key component to security testing would be to complete the code reviews. As noted, before, prior to any code being merged at T-Mobile, a code review is completed by a minimum of two members. This is crucial as code reviews not only look for logical errors and styling guidelines, but they are also extremely vital in identifying security vulnerabilities. After going through vigorous code reviews, we pilot our software through beta application testing, or through internal teams specifically assigned to test new internal software. During these releases we can use things such as penetration testing to test the application security. Finally, once the software has been fully released and it enters the maintenance phase, our teams continually test for new vulnerabilities to ensure that the system software remains secure. Unit 2: Software Assurance Techniques Analysis When developing a software assurance guide it is essential to determine which software assurance techniques can be applied to the applications within the company. In this section we will be reviewing a variety of applications that T-Mobile USA commonly uses on a frequent basis, where each of these apps pose a security risk, and a technique that can be used to counter act these risks. T-Mobile USA has exponentially grown over the course of the last decade both regarding its consumer group, its own employment group, and in the products that is has put out. With that growth has come a variety of new published software that is used to help ensure the products are running as intended. In addition to developing apps to run their products T-Mobile has created an internal system for its customer care team as well as a website for its own consumers to manage their account.

8 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A The first application we will review is T-Mobile’s Home internet application. This application is used in conjunction with T-Mobile Home Internet service. The app allows customers to take control of their modem. Once successfully paired customers can setup their internet, monitor usage, and set parental controls. Additionally, T-Mobile uses this application to ensure during the setup process customers are choosing the best location to place their modem for best results. A few security risks can be posed when using this application. The first security risk could be unauthorized access to the account through password sharing. In this situation, if a password is leaked or given out mistakenly, a bad actor can now gain full access into the customers WIFI control system and lock them out of their own system. Additionally, this use would then have access to sensitive data including general internet usage. One technique that could be implemented to curb this issue would be to implement a system generated password reset on occasion (Content & Engineer, 2021). While this may be considered cumbersome it ensures that in the case a password is leaked, users still can have secure control of their account. The second potential risk to this application is that if the end-user were to leave their device unattended with the application open there is a risk that someone can tap into their session and then again gain access to the account and exploit the customers information. A possible security assurance technique to address this issue would be to use session management. In doing so a session could be ended if there was no activity within a certain period, and to re-login credentials would have been reverified. The second application that T-Mobile incorporates into its products is its customer facing online website. Using My.T-Mobile.com, a customer can manage their T-Mobile account. Some of the actions a user may take includes viewing or paying their bill, checking usage, changing their rataplan, upgrade their devices, or activate new lines to their account. As you can see this

10 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A needs to be highly aware of is a injection attack. In this instance, information is sent to alter how the system would interpret a command, and from that the attacker can that manipulate the data or can unauthorized access. T-Mobile has unfortunately had a 3 major data breaches over the course of the last five years. One technique that could be used to address this would be to implement code that validates a user response. If the input can’t be validated, then there is no risk for something to be changed. Another security risk is that someone who should not have access to this tool gains access thru an unsecure connection. One way to resolve this conflict would be to implement a firewall. Guidelines The previous section where we looked at each of the potential security risks that T- Mobile faces through each of its different applications. Using that analysis this second part to the software assurance technique will provide a set of guidelines that T-Mobile can use to help with reducing future security risks. By following the recommendations listed below, T-Mobile can increase the protection to customer data and their own application. This will ensure that both T-Mobile customers and the corporation will remain safe. To keep with the general formatting of this document the first guideline we will look at is the T-Mobile home internet application. The first thing that T-Mobile should do is conduct code reviews on a continual basis. By implementing these code reviews those who work within the software department will be able to highlight code that may be vulnerable to security risks, or defects that could cause a security bug. In addition to completing these code reviews, T-Mobile also needs to ensure the application has strong encryption mechanism that ensure the data within the application is secure and any sensitive customer proprietary information.

11 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A The next application that was analyzed in part one was the my.T-mobile.com account management system. In this section we reviewed ensuring that strong session management techniques are in place. By implementing these session management techniques this will help with reducing the chances of a session hijack by a bad actor. The second guideline that T-Mobile needs to include is increased account validation techniques. An example of this would be to incorporate user credential verification. If the credentials do not pass the tests there should also be a lockout method inputted to avoid possible account takeover. The last application that we analyzed in the first section was T-Mobiles internal customer care software that acts as a liaison between T-Mobile’s account database and the customers questions. The first good practice for T-Mobile would be to ensure they perform scheduled backups on their database system. This is extremely important because it protects the company from outages and in some instances can help ensure the company has data it can turn back into in the case the newest data becomes compromoised. Additionally T-Mobile needs ensure they are implementing parameterized queries which will help with ensuring that there are a reduced risk of injection attacks. Unit 3: Security in Nontraditional Development Models Identifying Non-Traditional Security Model The next piece in this software assurance guideline document is being able to address security options that T-Mobile USA would be able to incorporate in a non-traditional development model. In addition to identifying the model, a brief synopsis of each of the major steps within that specific model. Additionally, at each of these steps this guideline will identify

13 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A may be given credentials allowing them to gain unauthorized access to the account (sciencedirect, 2010). The second step of the agile development process would be the product design stage. Within this stage using the information that was gathered from our initial phase, we know have the information to design a model that is feasible for the product. In addition to building out the model, the initial prototypes of the UX design can be implemented out. It is during this step it is essential to identify the areas of security risks. Examples of security risks in nature can range from unauthorized permissions given to a user, to technical requirements that can lead to increased security vulnerabilities. Once risks have been identified, they need to the be accessed to determine first the likelihood that the risk would come forth. As well as if it were to arise, what impact it would have on both the consumer and business level. The third step within the agile development process is the coding piece. In this portion of the development process, the prototypes of the product are handed over to the development team to put into action. During this process, the developers will bring the prototypes to life using an agreed upon language. One of the downsides to agile software development is that due to the customer input, there are rapid release cycles that can occur to meet the goals of the product owner. A part of this issue is that due to rapid development developers can in some cases lack security integration (Brathwaite, 2023). The fourth step to this process would to be to complete system testing. In this iteration, implementation testing will be complete. This portion can occur multiple times throughout the agile development cycle as new features or software can be inserted and redacted as the app is continually built out. The purpose of this is to ensure that the product is working as expected

14 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A during the acceptance criteria method. A security risk that is involved in this step is that as mentioned previously, due to the rapidly involving nature of the app, if updates are being pushed continually, there is a higher chance of security vulnerabilities. This is due to the fact of the quick turn-around time, and the ability for new bugs to arise with the quick addition of new code is larger. The final stage in agile development model would be the deployment and maintenance phase. As with any deployment applications or software products face a large variety of security risks. In cases, that products deal with database, you face injection attacks. In other software products you face unauthorized access, or large-scale traffic attacks to cause the software to break. Non-Traditional Software Development Policies & Processes The second section of Unit three is discussing policies and process that would be able to address a variety of security threats through each stage of the agile development cycle. By implementing these policies T-Mobile would be able to ensure the products and systems they are developing would be resilient and fend off software threats. During the planning and development stage that first policy that could be implemented to avoid security risks would be a security inclusion policy. The goal of this policy would be to ensure a specific section of planning would go specifically into software security requirements. In order to ensure the policy is deployed successfully, the cybersecurity team would overview any project plans, to ensure that the security requirements would be cover any major security threat.

16 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A Time monitoring should be implemented by the cybersecurity or IT team to help with detecting any real-time security risks. Section 4: Security Static Analysis In this section of the analysis, I will identify three commonly used security static-analysis tools and based upon those chosen I will prepare a guideline on how they could be used within the software development cycle within T-Mobile. This section will be broken up into two separate sections, the first identifying each of the tools followed by how it will be implemented on the account. Application Design Layout

17 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A Above our two separate screen shots that would depict different views of how the application would be viewed on the user side when fully logged in to the T-Mobile App. Component Diagram Major Components In the main T-Mobile user facing application there are total of five main components in the application. The first is the home page, in this section the user is provided the option to view their overall account usage (call, text history, and data usage). Additionally, they can add their payment method for autopay here as well. A major security risk here would be supplying this information to an individual who is not supposed to have access. If a situation occurs where call or texts records are given out can make the individual susceptible to hacking.

19 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A C++ Code Samples A common security risk that comes with C++ is buffer overflow. Buffer overflows can be caused when a built-in boundary check is not included. In a buffer overflow attack an attacker is able to inject things such as spyware into a program. Looking at the code above we can see that a buffer overflow attack is a possibility. This can occur if a user decides to enter a string that is longer than the User Input array. There are a multitude of ways that these issues can be prevented. Security Static-Analysis Tools & Guidelines The first static-analysis tool that is common is a static code analyzer ( Zelleke, 2023) . The purpose of this tool is to scan code to identify potential security vulnerabilities. Vulnerabilities

20 SOFTWARE ASSURANCE GUIDELINE – T-MOBILE U.S.A that this tool would be able to notify about include security scares include SQL injection and buffer overflows. An additional perk to this tool is that it will provide a report that provides in depth information about each of the vulnerabilities that were identified, as well as recommendation on how the security flaw could be shored up. The next tool that is popular is SonarQube, which is a platform that completes a static analysis on code to locate bugs, code issues, and security flaws within the code. One major benefit to SonarQube is that this tool can analyze a variety of different programming languages ( Zelleke, 2023) . This is major benefit because like the static code analyzer this tool provides a report that can help the team improve upon not only the security of the app but also the quality of the code. The last tool that can be used is called Checkmarx, and like the first two this program also identifies vulnerabilities within the code. Unlike the first two though this program specifically looks at issues such a file handling and communication protocols. The second piece of this subunit is to discuss how the tools listed above could be implemented successfully within T-Mobile’s software development. Below is a list of recommended guidelines I would suggest for them to use. The first thing is T-Mobile should implement each these tools into any previously released software, as well as ensure each is integrated into any future products. By implementing these tools into the development cycle, it will ensure they are scanning each product for vulnerabilities on a continuous basis throughout the build. As noted in previous guidelines, I would also suggest T-Mobile IT and software team come together to develop a set of standards for their coding that way all developers are on the same page and ensure their code is in compliance with these agreed upon standards. The next guideline I would put in place would be that as vulnerabilities are identified they are then provided a prioritization ranking depended on how impactful against the business it could be. In