CST499 - Week 2

What milestones did you accomplish this week?

This week I finished up my part of the research project. All my models have been trained against all my feature representations, and the results have been screenshotted and saved in documents. I have been in contact with my project advisor to keep her updated on my progress. Unfortunately, the meeting with Raytheon has been postponed until the 18th. It does not appear that we will be receiving data anytime soon. I updated Dr. Tao with this information, and he has requested a summary of my current contributions.  

What is your plan for next week?

Since finishing my tests took longer than expected, I still have to summarize my results for the team to review. I will use this summary as a basis for my summary to Dr. Tao. Other than that, my plan is just to start writing my paper unless something comes up. 

CST499 - Week 1

What project milestones did you accomplish this week? 

Conference Paper

This week I finished writing my part of a conference paper that is being reviewed by Dr. Thulasiraman. It contains a summary of all my work over the last few months involving feature extraction from 5G and Modbus PCAP files and the training and tuning of basic autoencoder models. This conference paper provides the basis for my current work.

Model Configurations

This week I created a convolutional autoencoder model. This was the final model I needed to build. I already tested it with the original feature representation (ICMP flood) using scaled and unscaled data. 

Feature Representations

I finished aggregating results for my “novel flows” idea using the basic autoencoder model. Rather than using “synthetic flows” to test my models (as before), I excluded a couple of real flows from training and marked their subflows as anomalous. The partitioning of the flows is also different from the previous work (forward flows vs. inward flows).

What is your plan for next week?

Over the next couple days, I am going to finish testing my models with all the feature representations I have. Three models are being compared for anomaly detection: Basic autoencoder, convolutional autoencoder, and KMeans. Feature representations include flows (forward and inward), MITM, and query responses. Results will be aggregated and sent to Dr. Thulasiraman for review. This will conclude my initial testing, although I do not expect any breakthroughs.

On Friday, Raytheon network engineers will be meeting with our team to discuss steps forward. We will be discussing the network architecture and concept of operations (CONOPS). Hopefully this results in new ideas for feature representations. I am going to ask questions about query response values I found in the Modbus data. I am also going to try to get an update on when we can expect new feature sets. 

 

The 5.4e+03 Second Litmus Test

This is a blog post from my late friend and mentor Frank Madrid. Posted February 24, 2018.

To a computer science student with no industry experience, few things are as unnerving as a technical phone interview. An interviewer must determine if the interviewee is slightly more proficient than a monkey using vim and implicitly assign a value to 4+ years of theoretical education and technical experience in under 5400 seconds.

Two days ago, I underwent such a litmus test with two Google interviewers and barring the heavy accent of my interviewers and the poor cellular connection, the interview process was a positive experience.

The Google Technical Internship Interview

A quick Google search immediately reveals the mystery and confusion surrounding the technical interview process. Forums are riddled with variants on the question, “What questions are asked during the Google Technical Interview?”

I assume the daunting and all-encompassing list of candidate topics indicated by Google in their 8-page Google Slide presentation is what solicits such a response.

In summary, these topics include:

• Algorithms
• Data Strucutres
• Operating Systems
• Mathematics

Though a list of four topics may seem far from all-encompassing, any second-year computer science student with 10 fingers (yes, a binary joke) can count how many classes do not use some subset of these topics. The possibly sole class meeting this requirement includes Introduction to Programming where the concept of an algorithm is barely introduced amidst the hurried foray to understand proper C++ or Java language syntax.

Preparing for the Technical Interview

Two weeks were spent reviewing and practicing these concepts in preparation for the technical interview. I attempted to find sources which offered a breadth of knowledge but didn’t require tremendous effort to understand any particular topic, and a slew of problems to reinforce the concepts learned during the review.

Reference Material

The first, and highly recommended text is The Algorithm Design Manual. This text offers an introduction to the most important data structures and sorting algorithms without being weighed down by heavy symbolic notation. It also offers a catalog of algorithmic problems which is useful for solving challenging coding questions. It also offers amazing interview questions but lacks a corresponding solution manual. This text is is available from Amazon for about $40.

The second, and widely popular text, Cracking the Coding Interview, boasts good insights into the interview process and includes detailed solutions to many important (but publicly available) problems. This one is available from Amazon for about $30.

Practice Problems

Cracking the Coding Interview included many problems targeted at a specific topic but most of my beneficial practice was found on websites dedicated to hosting a plethora of programming questions such as LeetCode. These problems did not necessarily indicate the appropriate data structure or algorithm to solve the problem and were sufficiently vague enough to be thought provoking yet not misleading. Solutions to some of the more interesting problems may be featured in future posts but many, if not all, of my solutions can be found on Github in my public repository.

The Interview

After the usual introductions and pleasantries, I was excited to finally begin the technical interview and witness what exciting problems the Google software engineers would be challenging me with. The questions were of average difficulty, completable within 30 minutes, and didn’t require a brilliant or archaic solution. The three solutions required string manipulation, the use of basic repetition structures and binary arithmetic operators, recursion, dynamic programming, and Big-O analysis.

I was not explicitly asked to withhold any information regarding the interview, but the specific content of the interview was indicated to be confidential.

As is commonly stated in their publicly available presentations: the interviewer is more so interested in interviewee’s ability to analyze and solve a problem than their ability to code. A fundamental understanding of the chosen programming language is of course required, but my interviewers allowed the use of loose pseudocode to explain ideas which would have required multiple lines of instructions. After each implementation, the interviewers indicated particular instructions which would have resulted in errors and allowed me the opportunity to identify and correct the error before moving on.

Final Thoughts

Being my first internship technical interview, I allocated a large percentage of my free (and not so free) time to the review of concepts which had the potential to be discussed during the interview. In actuality, hardly any topics I specifically reviewed were discussed. All questions would have been answerable without the review but not with the level of detail I was able to provide. In hindsight, the amount of preparation, though appropriate for a full-time position, was overkill for an internship.

Within two weeks, I will hopefully hear about candidate projects which are viable with my skillset. If not, then I will have to consider other internship opportunities.

CST 438 - Week 8

5 important things I learned in the course

Software Engineering is not programming

One of the questions I had coming into this course was how software engineering is different from software development. I was already aware of the controversy over calling oneself an "engineer" as a software developer. While that issue may never be resolved, and the titles are often used interchangeably, I do see how there is a difference from a regular programmer and one who applies engineering principles to software development. Software developers write code just like software engineers, but "software engineering is programming integrated over time" (Software Engineering at Google). Software engineering focuses on project sustainability, scale, trade-offs, and costs (financial, resource, personnel, societal, etc.). This means that software engineers have a greater responsibility than just writing code and follow a different set of "best practices" than your average software developer.

Agile Software Development

As stated in my previous blog post, Agile focuses on continuous releases and frequent customer feedback, allowing dev teams to be flexible and able to adapt to changing requirements. Some of the key Agile concepts include user stories, daily meetings, small teams, incremental development (each version builds upon the previous version), and iterative development (redesigning previous work). The Agile lifecycle repeats itself throughout the product's life span. One of the tools I was exposed to is Pivotal Tracker. It allows dev teams to easily create and track user stories and also to gauge their "velocity," or speed of development per iteration. 

Full Stack Web Development

Another concept that I was eager to learn about is what exactly "full stack" development entailed. Now I know that it just refers to developing both the front and back ends of a web application. Some people may specialize in one or the other, but a full stack developer is knowledgeable in developing both ends. This course provided some really good practice in this area, from the Spring Boot back end (and its use of JPA/Hibernate to communicate with the database) to the React front end. I had heard a lot about React but never knew exactly what it is. Now I know it is just a JavaScript library created by Facebook that allows for easy front-end development. It was also interesting to learn about service-to-service communication using tools like RabbitMQ.

Code Testing

Testing is one of the most important parts of development. Although writing tests can be time consuming, shipping broken code is embarrassing and can result in people losing faith in your software. There are different kinds of tests ranging from small to large scale. I think learning about unit tests (with JUnit and mocks) was a really important concept because I see a lot of job listings that require experience with them. However, I actually had a lot more fun with the large scale, end-to-end tests (with Selenium). 

System Requirements Specification (SRS)

Although we were only assigned an abbreviated SRS, I think it was still good exposure to documenting technical requirements. An SRS focuses on "what the software needs to do and how it must perform." One of the parts we focused on was providing the framework for our use cases. This turned out to be useful to me because I recently had to read a technical document for my internship that spelled out use cases for the system under development. My exposure to SRS writing made me feel much more comfortable when reading through and understanding the document.

CST 438 - Week 7

Agile vs Waterfall

Agile and Waterfall are two approaches to software development. Agile focuses on continuous releases and frequent customer feedback. It allows dev teams to be flexible and able to adapt to changing requirements. This is in contrast to waterfall project management, an approach that uses a clearly defined path with limited deviation. Customer interaction with the product doesn't occur until the end of development. This rigid approach works well when the development process is predictable. However, if anything goes wrong or needs to change, the dev team may experience costly setbacks and delays. The pros and cons of each should be carefully considered before choosing an approach.

CST 438 - Week 6

Security Vulnerabilities

This week I learned more about web-based security vulnerabilities. Some I was already familiar with, like SQL injection and DoS attacks. Others I either had not heard about or did not understand the technical details, like CSRF, XSS, and CORS. 

• CSRF (Cross-site Request Forgery) attacks allow attackers to send data to a website that you are already logged into. If the legitimate site relies only on session cookies for validation of user requests, it is possible for a malicious site (that you happen to visit) to take advantage and make HTTP requests using those session cookies. This may result in passwords being changed or information being stolen. One way to mitigate this attack is for the legitimate website to include a CSRF token with all requests. Tokens should be unpredictable and tied to a user's session. If the token is invalid or missing, the request is rejected.
• XSS (Cross-site Scripting) attacks allow attackers to "trick" web servers into returning malicious JavaScript code to their users. This can happen if user input is not properly filtered. For instance, if a website stores user input in a database for later viewing by other users (such as a car sale listing website), a malicious user could include <script src="..."> in their listing which would then be delivered to other users who view the listing, resulting in their browser running the malicious script. Attackers can use this to steal session information and impersonate a legitimate user, potentially stealing sensitive data like credit card information. One way for websites to mitigate this is to prevent users from including angle brackets in their input by replacing them with &lt and &gt, respectively.
• CORS (Cross-origin Resource Sharing) is a policy that allows web servers to request resources from other web servers outside their domain. For example, website foo.com may need to request a resource from bar.com (like an image file). However, web browsers do not automatically allow cross-origin requests due to their same-origin policy. This means that web servers must explicitly allow requests from outside their domain. If a web server implements its COR policy improperly (e.g., using wildcards in whitelisted domains) or makes it too lax (allowing requests from any domain), attackers can take advantage. 

OAuth 2.0 Message Flow

I also learned about OAuth 2.0, an authentication protocol that allows clients to access resources from web servers on behalf of a user. An example message flow is as follows. A client sends a login request to a web server which redirects the user to an authorization server (e.g., Google). The user enters their credentials, and the authorization server authenticates the client. The authorization server returns an access token to the client which is redirected back to the web server. The web server uses the access token to obtain information about the user from the authorization server (e.g., Google profile information) and informs the client that login was successful.

CST 438 - Week 5

Unit Testing vs. End-to-End Testing

A unit test targets a specific behavior, usually a method or an API, and should be limited to a single process. Unit tests abide by the FIRST principles: Fast, Isolated, Repeatable, Self-validating, and Timely. 

• Fast: If unit tests are not fast, they will slow down development time. If a test takes 5 minutes to run and must be run multiple times a day, it will lead to reduced productivity.
• Isolated: Unit tests do not depend on the results of other tests, and they focus on one specific behavior.
• Repeatable: Tests should produce the same result each time they are run. 
• Self-validating: The tests themselves verify whether they have passed or failed. There should be no manual interpretation of results because it takes too much time.
• Timely: Unit tests should be written alongside the code they test. The sooner code is tested, the better.

End-to-end (E2E) tests, in contrast, target a larger part of the system. These tests focus on user workflow and simulate real-world use cases. They use real browsers and databases instead of mocks. This type of testing is important because it expands test coverage (rather than focusing on a single behavior) and verifies that an application behaves correctly in response to end-user activity. However, end-to-end tests are more difficult to implement and can be time consuming.