Echoes in the Storm

In the quiet corners of his mind,
A storm swirls, leaving peace behind.
Thoughts race like leaves in a restless breeze,
Yet he's anchored, trapped, on shaking knees.

Loneliness whispers in every sound,
A hollow echo that knows no bound.
The world moves on, but he's out of sync,
Drowning in the chaos where others think.

A spark of hope, a fleeting flame,
Extinguished quickly, the dark's to blame.
Focus shattered, time slips away,
Another lost hour, another gray day.

And yet, within this shadowed strife,
Flickers a will, a thread of life.
Though heavy the burden, deep the despair,
A quiet strength reminds he's still there.


 

BSIT400 - Week 12 Posting - Exploring the Benefits of Infrastructure as Code (IaC)

Infrastructure as Code (IaC) manages IT infrastructure through configuration files, allowing teams to automate and standardize deployments rather than manual processes. In IaC, administrators define infrastructure needs—like servers, networks, and storage—using code, transforming infrastructure management into a process similar to software development (Microsoft, n.d.).

One of IaC’s core benefits is consistency. With every piece of infrastructure described in the code, deployments across environments, such as development, testing, and production, remain consistent. This approach reduces “configuration drift,” which often results from manual changes that complicate troubleshooting and system management over time. When environments match in configuration, applications become more reliable and supportable (Red Hat, n.d.).


IaC also enhances
efficiency and speed. With tools like Terraform, Ansible, or AWS CloudFormation, IaC enables quick infrastructure deployment and on-demand scaling. Automated deployments reduce setup time and minimize human error, allowing faster, more reliable updates. This adaptability improves cost efficiency as resources can be scaled up or down according to demand, optimizing infrastructure expenses (HashiCorp, n.d.).


Furthermore, IaC fosters
collaboration by allowing infrastructure configurations to be stored and versioned in repositories, similar to software code. Teams can track changes, roll back to previous configurations if needed, and test updates before applying them to production. By treating infrastructure as code, IaC promotes faster iteration, fewer errors, and greater scalability, aligning IT practices with today’s demand for agility (Amazon Web Services [AWS], n.d.).


References

Amazon Web Services. (n.d.). What is infrastructure as code? Retrieved from https://aws.amazon.com/what-is/infrastructure-as-code/

HashiCorp. (n.d.). Infrastructure as Code with HashiCorp Terraform. Retrieved from https://www.hashicorp.com

Microsoft. (n.d.). Overview of infrastructure as code. Retrieved from https://docs.microsoft.com

Red Hat. (n.d.). What is infrastructure as code? Retrieved from https://www.redhat.com 



A "wrap-up" of my Blogging experience:

  • What did you find enjoyable or not about this assignment?
    • I enjoy the creative writing involved in making these posts.
  • Was it helpful to you in your current job?
    • My current job title is "Principal Systems Engineer," and I've been in IT for 40 years. No, not really.
  • Can you see yourself Blogging in the future when it isn't required for an assignment?
    • Yes, I can. Researching a subject and creating something people will want to read is fun.
  • Can you see this ability as desirable for a company, giving you more weapons in your arsenal and making you a more attractive hire?
    • No, not at all. No company has ever asked me to produce any writings other than technical documentation.

BSIT400 - Week 11 Posting - Understanding RTO and RPO: Key Metrics for Effective Disaster Recovery Planning

When organizations plan for disaster recovery, two critical metrics guide the process: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Although often mentioned together, RTO and RPO serve different purposes in helping a business recover from unexpected disruptions. Both metrics help define acceptable downtime and data loss levels, allowing organizations to create a recovery strategy that meets their operational needs and budget.

The Recovery Time Objective (RTO) refers to the maximum time a business can tolerate being offline after a disruption before it starts to experience serious consequences. RTO answers, "How long can we afford to be down?" For example, if a company has an RTO of four hours for its email system, it must restore email access within four hours to avoid significant impacts on business operations. RTO helps businesses prioritize which systems and services need to return to service quickly to minimize financial loss or operational setbacks.


On the other hand, the
Recovery Point Objective (RPO) focuses on data loss tolerance. RPO determines how much data a business can lose by setting a time limit for data recovery. For example, if an organization has an RPO of one hour, it means that, in the event of a failure, data recovery should bring the system back to a state no older than one hour before the incident. This requires frequent data backups or replication. Together, RTO and RPO are essential in disaster recovery planning. RTO addresses downtime limits, while RPO manages data loss limits, helping organizations create balanced recovery strategies based on their needs.

BSIT400 - Week 10 Posting - Data Obfuscation 101: Understanding Encryption and Tokenization in Today’s Digital World

In today’s digital world, data breaches are becoming more sophisticated, and protecting sensitive information is more crucial than ever. This is where data obfuscation techniques like encryption and tokenization come into play. These methods serve as essential shields to keep personal, financial, and business-critical data safe from prying eyes.


Encryption
is the most well-known method. It converts readable data (plaintext) into a scrambled format (ciphertext) using algorithms and keys. Only someone with the proper key can decrypt and make sense of it. Encryption secures everything from private messages to banking information, whether the data is being stored or transferred. The catch? The safety of encrypted data heavily depends on managing and protecting those keys. If a key falls into the wrong hands, the data becomes vulnerable.


Tokenization
, on the other hand, works differently. Instead of scrambling data, it replaces sensitive information with non-sensitive placeholders called tokens. For example, your credit card number could be swapped with a random token that maps back to the actual number in a secure vault. This method is beneficial for payment processing, as even if a hacker gets a hold of the token, it’s worthless without access to the original data.


While both techniques enhance security, they have different strengths. Encryption is versatile but requires diligent key management, while tokenization is ideal for safeguarding specific data elements, like credit card numbers, in compliance-heavy environments. Companies often combine both methods to create robust data protection strategies that balance performance, security, and regulatory needs.


Understanding these techniques is critical to securing our digital world, with cyber threats rising. Whether you’re an IT professional or a concerned internet user, knowing how your data is protected can give you peace of mind in our increasingly connected world.

BSIT400 - Week 9 Posting - Safeguarding Digital Trust: The Crucial Role of Key and Certificate Management

Key and certificate management are critical components of modern cybersecurity. Keys, whether for encryption or signing, and digital certificates, which authenticate identities online, must be managed appropriately to ensure the security and integrity of communications and data in any organization.
Proper key management ensures that encryption keys are stored securely, regularly rotated, and used appropriately to protect sensitive data. If encryption keys are compromised or mismanaged, encrypted data becomes vulnerable to unauthorized access, undermining the entire security system. Managing keys also includes ensuring they are securely shared between parties, preventing them from being intercepted during transmission.

On the other hand, certificate management involves issuing, renewing, and revoking digital certificates that verify the authenticity of websites, applications, and users. Secure communication channels, such as those established using SSL/TLS, can be compromised without well-maintained certificates. Expired or invalid certificates can lead to security warnings or open the door to man-in-the-middle attacks where attackers impersonate legitimate entities.

Both key and certificate management are essential for maintaining the trustworthiness of systems and data exchanges. Without effective management, businesses can face serious risks, including data breaches, loss of customer trust, and non-compliance with security regulations, ultimately threatening their overall security posture.

Reference

What is certificate management?: SSL/TLS Certificate. Encryption Consulting. (2024, September 19). https://www.encryptionconsulting.com/education-center/what-is-certificate-management/


 

Whispers at the Door

The night is still, yet something feels amiss,
As children come for treats and playful bliss.
I smile and drop the candy in their bags,
But shadows stretch, and time begins to lag.

Each face I see, a mask, but not quite right,
Their hollow eyes reflect the fading light.
They shuffle close with whispers soft and cold,
My hands grow numb, the candy turns to mold.

They’re not the ones I thought I'd see tonight—
Too late I shut the door against the night.

BSIT400 - Week 8 Posting - Cloud Security Practices

Cloud security is a growing concern, and effective troubleshooting methods are essential for keeping systems safe. One popular methodology is Root Cause Analysis (RCA). This approach involves identifying the underlying cause of an issue to prevent it from happening again. For example, if a cloud server experiences unauthorized access, you must investigate how it occurred and address the vulnerabilities that allowed it. Penetration testing is another valuable strategy. By simulating attacks, organizations can discover weaknesses in their cloud infrastructure before malicious actors do.


The
Six-Step Troubleshooting Process is widely used for resolving cloud security issues. This process involves identifying the problem, gathering data, forming a hypothesis, testing the hypothesis, implementing a solution, and monitoring results. This method ensures that all angles are covered when addressing security incidents. Another essential tip is to monitor logs and alerts constantly. Cloud environments provide rich logging data, which can help administrators detect suspicious activity early. Regular audits of user permissions, data encryption methods, and security protocols also play a vital role in maintaining cloud security.

Maintaining cloud security requires a combination of proactive and reactive strategies. Troubleshooting security issues effectively involves thorough investigation, regular testing, and constant vigilance.

For further reading on cloud security strategies, check out the IBM Cloud Security webpage (IBM, What is cloud security? 2024), which provides an overview of cloud security best practices, including methods for identifying and mitigating risks and tips on maintaining security in cloud environments.

 

Reference:

IBM. (2024, October 1). What is cloud security? https://www.ibm.com/topics/cloud-security




 

 

BSIT400 - Week 7 Blog Posting - Article Review

For this weeks blog entry, I have decided to provide a review of an interesting article titled "What's the difference between cloud computing and colocation?", written by Alex Carroll and published on the Lifeline Data Centers website at https://lifelinedatacenters.com/colocation/whats-the-difference-between-cloud-computing-and-colocation/. 

The article offers a clear comparison between cloud computing and colocation, two approaches businesses can use for data storage and computing power. Cloud computing provides access to virtualized resources over the internet, making it ideal for companies looking for scalability without investing in physical infrastructure. Conversely, colocation allows businesses to rent space within a data center to house their own servers, providing more control over their hardware but requiring higher upfront investments.

The article makes a strong case for cloud computing's flexibility, especially for startups and smaller businesses that need scalable solutions without the overhead of managing physical servers. By offering virtualized environments, cloud computing reduces the cost of entry and ongoing maintenance. It also simplifies scaling up or down based on the business's needs, a significant advantage in a rapidly evolving market.

In contrast, the article highlights the advantages of colocation for larger companies with more specific requirements. These companies often choose colocation because it allows them to maintain greater control over their hardware and network configurations. Businesses that have invested in physical servers may find colocation a better option, as it helps ensure they meet compliance requirements while keeping their data secure in a professional data center environment.

The article provides valuable insights into how cloud computing and colocation serve different needs. While cloud computing is often favored for its ease of use and scalability, colocation remains a strong option for businesses seeking more control over their physical infrastructure. The choice ultimately depends on each business's specific needs, budget, and long-term goals.

Reference:

Carroll, A. (2017, June 12). What’s the difference between cloud computing and colocation? Lifeline Data Centers. https://lifelinedatacenters.com/colocation/whats-the-difference-between-cloud-computing-and-colocation/




BSIT400 Week 6 Posting - What is a Virtual Private Cloud?

A Virtual Private Cloud (VPC) in Amazon Web Services (AWS) allows you to create a logically isolated network within the AWS cloud, giving you control over your virtual environment. Think of it as your private data center in the cloud, where you define everything from the IP address range to how your network routes traffic.

When you create a VPC, you start by defining the IP address range for the network using CIDR (Classless Inter-Domain Routing) notation. You then divide this network into smaller sections called subnets, which can be either public or private. Public subnets can directly communicate with the internet, while private subnets stay isolated unless you specifically allow access. For example, a web server can be placed in a public subnet, and a database server can be placed in a private subnet to protect sensitive data.

Each VPC automatically comes with a default route table, which controls traffic flow within your network. You can also create custom route tables to define more specific rules. AWS provides a virtual internet gateway for public subnets to access the internet. For secure connections between your on-premises network and your VPC, AWS offers a Virtual Private Gateway, allowing you to extend your private data center to the cloud securely.

Security in a VPC is handled through Network Access Control Lists (ACLs) and Security Groups. These allow you to define which IP addresses or ranges can access specific resources in your VPC, providing a layered approach to securing your cloud infrastructure. A VPC gives you complete control over your network environment, from designing subnets to managing traffic routing, ensuring you can securely run applications in the AWS cloud.

Reference: 

Amazon. (2024). What is Amazon VPC? - amazon virtual private cloud. Amazon Web Services. https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html


 

Short Story: The Guardian of the Obelisk

Rick Mason stepped outside his small ranch house in Omaha, Nebraska, feeling the crisp autumn air bite at his skin. At 60, Rick had seen his share of mysteries—both in his time as a Master Mason and from decades of studying arcane lore and ancient symbolism. However, tonight, something different tugged at him. It wasn’t the usual chill of the Midwestern breeze; it was a feeling deep in his bones, something uncanny that had been gnawing at him all week.

Rick wasn’t just any Mason. As the current Master of his Lodge, he was well-respected in the community for his wisdom, his calm demeanor, and his ability to see past the surface of things. But even with years of experience, nothing had prepared him for the strange occurrences that had begun to plague him. His dreams had been vivid and bizarre—filled with images of an ancient obelisk hidden deep beneath Nebraska’s seemingly ordinary landscape. The dreams were so real, they were more than mere dreams—Rick knew they were something else, something calling to him.

The dreams always began the same way. Rick found himself in a cornfield, tall stalks rustling in the wind as the moon cast eerie shadows across the rows. A pathway would open up between the crops, leading him toward a colossal black obelisk, inscribed with strange symbols. He could never get too close to it; something would always wake him just before he could reach out and touch the cold stone.

Rick shook his head as he unlocked his car, trying to push the unease away. Tonight, he had Lodge business to attend to. It was the annual meeting where he, as Master, would oversee the admission of a new member—always a solemn and important affair. However, something told him that tonight’s meeting would be far from routine.

He arrived at the Lodge, a century-old building nestled between modern storefronts. The Masonic Hall had stood the test of time, a relic of an age where mystery and fraternity went hand in hand. Inside, the walls were adorned with symbols—compasses, squares, and the all-seeing eye—while the rich smell of old wood and incense filled the air. Rick took a deep breath, feeling a sense of familiarity and calm wash over him, but only for a moment. There was still that gnawing feeling of something off-kilter.

As the brethren arrived, Rick greeted each of them, shaking hands and exchanging pleasantries. Tonight, they would initiate Mark Smith, a local businessman, into the fraternity. Mark had come highly recommended, but Rick couldn’t shake the strange feeling that had settled into his bones.

As the meeting commenced, Rick took his place at the East, the seat of the Master, and began the opening ritual. The room fell silent as the members of the Lodge followed their practiced routines. But halfway through the ceremony, a strange thing happened.

The power flickered. The lights dimmed, casting long shadows across the room, and for a brief moment, Rick thought he saw the outline of the obelisk from his dream, standing in the corner of the Lodge. He blinked, shaking his head. It was gone in an instant, but his heart raced.

"Are you alright, Worshipful Master?" asked one of the brothers, concern etched in his voice.

Rick forced a smile and nodded. "I'm fine. Let’s continue."

But Rick knew he wasn’t fine. The visions were becoming stronger, more real. He glanced at Mark Sanders, who was kneeling before the altar, and felt an uneasy pull in his gut. There was something about the man that seemed… off. Not in a malicious way, but as if Sanders wasn’t entirely of this world. His demeanor was calm, almost too calm, and his eyes seemed to glow faintly in the dim light of the Lodge room.

After the meeting, Rick lingered behind while the other brothers left, unable to shake the feeling that something important was about to happen. He wandered the Lodge’s antechambers, his mind still racing with thoughts of the obelisk. What did it mean? And why was it haunting him?

As Rick approached the door to the old storage room in the back of the Lodge, a cold draft swept past him. The door creaked open on its own, revealing a space that had remained untouched for decades. Rick stepped inside, squinting in the darkness, when he noticed something unusual—a faint glow coming from behind a stack of old boxes.

His heart pounded as he moved the boxes aside to reveal what was causing the glow. There, nestled against the wall, was a strange stone tablet. It was covered in the same symbols he had seen on the obelisk in his dreams. Rick knelt down, tracing the strange inscriptions with his fingers. The tablet felt warm to the touch, as if it were alive.

Suddenly, the ground beneath Rick shifted. The walls of the Lodge seemed to bend and twist, and before he could react, Rick found himself no longer in the storage room but standing in the middle of a vast cornfield under a moonlit sky. The familiar rustling of the corn surrounded him, and in the distance, the obelisk loomed.

This time, Rick was able to move closer. He felt an invisible force guiding him toward the towering stone structure. His heart raced as he approached it, the ancient symbols glowing brighter with every step. He reached out, his fingers brushing the cold stone, and instantly, a surge of energy pulsed through him.

In a flash, visions exploded in his mind—images of long-forgotten civilizations, of beings not of this Earth, and of Nebraska as it had been centuries ago, a place of great power and mystery. The obelisk, it seemed, was a remnant of an ancient race that had once lived beneath the soil of the Great Plains. And Rick, for reasons he couldn’t yet understand, had been chosen as its Guardian.

As the visions subsided, Rick found himself standing in the cornfield once again, the obelisk towering above him. But now, it was different. Now, he understood. The obelisk wasn’t just a relic of the past; it was a beacon, a gateway to another realm—one that was trying to open.

Suddenly, a voice echoed through the night, deep and resonant.

"Rick Mason," it said, "you have been chosen."

Rick turned, searching for the source of the voice, but found nothing but darkness. His heart pounded in his chest as the voice continued.

"You are the Guardian of the Obelisk. The key to the ancient door lies within you. Protect it, for dark forces are stirring."

Before Rick could respond, the world around him shifted once again, and he found himself back in the storage room of the Lodge, the stone tablet still glowing faintly at his feet. His head spun as he tried to process what had just happened. He had seen things—impossible things—yet he knew deep in his heart that they were real.

The obelisk was not just a symbol from his dreams; it was part of something far greater, something that had been hidden beneath the soil of Nebraska for centuries. And Rick, for reasons he couldn’t yet fathom, had been drawn into its orbit.

Breathing heavily, Rick picked up the tablet and placed it carefully in a leather satchel. He had no idea what lay ahead, but one thing was clear: his life had just taken a turn into the unknown, and he was now part of a mystery that spanned time and space.

As he exited the Lodge that night, the moon hung high in the sky, casting long shadows across the quiet streets of Omaha. Rick glanced back at the Lodge, a strange mixture of dread and excitement swirling within him. He had always been a seeker of truth, and now it seemed that truth was seeking him.

The Guardian of the Obelisk had been awakened, and whatever came next, Rick knew he had a role to play.

With the tablet in hand, he started his car and headed home, knowing that the mysteries of the obelisk, and perhaps even the fate of the world, rested on his shoulders.

And this was only the beginning.

The End.

BSIT400 - Week 5 Posting - Cloud networking concepts and considerations

When transitioning from a local physical network to a cloud-based network, several important cloud networking concepts and considerations need to be understood. One of the primary differences between a physical network and a cloud network is the reliance on the Internet or wide-area networks (WANs) for data transmission. In a physical network, devices and servers are typically connected directly to each other, making data transfer faster and more secure. However, data must be sent across the Internet in a cloud network, introducing additional concerns such as latency and security risks.

A key concept in cloud networking is virtualization. In a physical network, servers, storage, and networking equipment are dedicated to specific tasks. Cloud networking relies on virtualized resources, meaning that computing power, storage, and even networking components are shared across multiple users. This approach allows for greater flexibility and scalability, but it also requires careful management of resources to avoid bottlenecks or downtime.

Another consideration is security. While physical networks are often easier to secure due to their isolation, cloud networks face additional challenges. Data must be encrypted to protect it while it is being transmitted over the Internet, and access controls must be put in place to ensure that only authorized users can access sensitive information. Additionally, compliance with regulations, such as GDPR or HIPAA, may be necessary, depending on the industry.

Lastly, transitioning to a cloud network involves rethinking network architecture. Traditional physical networks are typically designed for a static environment, but cloud networks must be designed for flexibility and scalability. This means choosing the right cloud service models (IaaS, PaaS, SaaS) and optimizing configurations to handle changing workloads without losing performance or security.

References

IBM. (2024, August 12). What is virtualization? https://www.ibm.com/topics/virtualization

AWS, A. (2024). What is cloud networking? - cloud networking explained - AWS. What is Cloud Networking? https://aws.amazon.com/what-is/cloud-networking/

Lanfear, T. (2024). Secure networks with Zero trust. Microsoft Learn. https://learn.microsoft.com/en-us/security/zero-trust/deploy/networks


BSIT400 - Week 4 Posting - Exploring the connection between migrating to the cloud, and Project Management.

Migrating an organization’s IT resources to the cloud is a complex process that requires strategic planning and project management to ensure a smooth transition. Whether a single application or an entire network, the process is broken into five major phases: assess, plan, migrate, validate, and manage. Each phase is connected to the core principles of project management, ensuring that resources are effectively utilized, risks are minimized, and goals are met. In the assessment phase, project managers evaluate the organization’s existing IT infrastructure, identifying which systems are suitable for cloud migration and determining potential risks and benefits. This step is essential for creating a solid foundation for the project.
The planning phase is where the detailed work begins. Project managers define the scope, timeline, budget, and resources needed for the migration. Planning also involves mapping out the technical steps to move data and applications to the cloud, ensuring minimal disruption to business operations. Including risk management strategies to handle potential issues, such as downtime or data loss, is essential. During the migration phase, the project management team ensures everything is executed according to the plan. Clear communication and coordination between teams are vital in handling any challenges during the migration.
After the migration, the validation phase thoroughly tests the migrated systems to ensure everything functions as expected. Finally, the management phase ensures ongoing support, optimization, and security in the cloud environment. Proper project management throughout this process ensures that organizations can enjoy the full benefits of cloud technology, including scalability, flexibility, and cost-efficiency, without compromising performance or security. When done correctly, cloud migration enhances business operations and opens up new possibilities for growth and innovation.

Reference: 

KOIA. (2024, February 8). The rule of 6 PS. LinkedIn. https://www.linkedin.com/pulse/rule-6-ps-koiasoft-derwe

 West, J. (n.d.). CompTIA Cloud+Guide to Cloud Computing

BSIT-400 Week 3 Posting - Cloud Computing and Vendor Lock-in

In Joe McKendrick's Forbes article, he explains that the cloud computing industry faces a significant challenge with vendor lock-in, limiting innovation and flexibility for businesses. As companies increasingly adopt cloud services, they become dependent on specific providers' proprietary technologies, making it difficult to switch to other platforms or integrate new services. This dependency restricts companies' ability to negotiate better deals or leverage advancements from competitors.

McKendrick argues that this reliance on single vendors is pushing the industry backward. Instead of promoting openness and interoperability, many cloud providers create ecosystems that trap customers within their platforms. This limits the flexibility that cloud computing initially promised. Businesses, in turn, may be forced to either stay with their current provider or undergo costly and complex migrations. The article calls for the industry to embrace more open standards to prevent vendor lock-in from stifling future innovation.

Reference: 

McKendrick, J. (2011, November 28). Cloud computing’s vendor lock-in problem: Why the industry is taking a step backward. Forbes. https://www.forbes.com/sites/joemckendrick/2011/11/20/cloud-computings-vendor-lock-in-problem-why-the-industry-is-taking-a-step-backwards/#561995955e86


The Signal

In 1990, Staff Sergeant David Carson was stationed at RAF Bentwaters, a United States Air Force base in the English countryside. It was a quiet posting, nestled in the misty woodlands of Suffolk, where the damp fog rolled in early in the mornings and hung in the air until well after dusk. David was a communications specialist, working long hours in a windowless bunker filled with equipment that hummed softly, its fluorescent lights casting an eerie glow over the consoles.

He had been at Bentwaters for three years, part of the routine Cold War watch. The world was changing—tensions between the superpowers were easing, and there was talk of the Berlin Wall coming down. For David, it meant more boredom than excitement. The days blurred together, filled with endless monitoring of encrypted transmissions, routine checks, and waiting for messages that rarely arrived.

But on one rainy September night, everything changed.

David was working the midnight shift, alone in the communications room. The dull hum of the machines was almost soothing, and he leaned back in his chair, stretching his tired arms. The rain tapped steadily against the metal roof, lulling him into a trance. Just as his eyes began to droop, something unusual caught his attention.

The equipment crackled with static, a sound that normally wouldn't have bothered him. But then the static shifted, growing louder and more distinct, as if trying to form words. He straightened in his seat, his heart beginning to pound. It was common to pick up random bursts of interference, but this was different. The pattern was deliberate, almost rhythmic.

David reached for the headset and adjusted the frequency. The crackling intensified, and through the hiss, he could make out something—numbers, spoken in a calm, monotone voice.

"Four. Two. Seven. Nine. Zero. Six. Three."

He froze. The voice was faint but clear enough to send a chill down his spine. It wasn’t a transmission from the base or any military signal he recognized. It was coming from an unassigned frequency, one that shouldn’t have been active.

David quickly recorded the transmission, his hands shaking slightly. He had no idea where it was coming from, but he knew it was something important. The numbers continued for several minutes before abruptly cutting out, leaving the room in an eerie silence.

He rewound the tape and played it again, listening closely. The numbers were precise, spoken by the same calm, robotic voice. But there was something else beneath the numbers—something he hadn’t noticed at first. A faint, almost imperceptible sound, like whispering, hidden in the background.

David’s skin prickled. He couldn’t make out the whispers, but they sent a wave of unease through him. He quickly ran a trace on the signal, hoping to pinpoint its origin, but the results were baffling. The signal wasn’t coming from anywhere within the usual ranges—not from the base, not from a nearby town, not even from a satellite. It was as if it were coming from nowhere.

Feeling the weight of something strange in the air, David decided to report the anomaly to his superior, Master Sergeant Lewis, a no-nonsense career man who had seen it all. He took the tape to Lewis, explaining the strange transmission and the untraceable signal.

Lewis listened to the tape, frowning deeply. After a few minutes, he took off the headphones and sighed.

"David, this is probably some kind of atmospheric interference. Maybe a glitch from one of the old satellites. We’ve picked up weird stuff like this before."

David shook his head. "It’s not a glitch. I ran the numbers through the system. It’s too precise to be random interference."

Lewis narrowed his eyes. "I don’t like this, Carson. I’ll have Intel take a look, but don’t go talking about this to anyone. Understand?"

David nodded, though the sinking feeling in his stomach remained.

For the next few days, the incident weighed heavily on David’s mind. He went about his duties, but his thoughts kept returning to that night, to the whispers beneath the numbers. Then, a week later, it happened again.

This time, the transmission was stronger, clearer. The numbers repeated, and the whispers were louder, almost like a conversation. David recorded it again, this time playing the tape back at different speeds. Slowing it down, he realized the whispers weren’t random—they were in English, but distorted.

"Help… us…"

David’s blood ran cold. He ran another trace on the signal, but the results were just as baffling as before. He checked the logs—no authorized transmissions were being broadcast at that frequency. As far as the equipment was concerned, the signal didn’t exist.

Frustrated and unnerved, David took the new recording to Master Sergeant Lewis. But when he arrived at Lewis’s office, something was off. Lewis wasn’t there, and no one seemed to know where he had gone. It was unusual for him to disappear without notice.

Over the next few days, things grew even stranger. More transmissions came through—each one more intense than the last, with the whispers growing louder, more insistent. The base seemed to be on edge, with rumors of strange occurrences spreading among the airmen—people hearing voices over their radios, strange lights flickering in the sky at night.

David tried to ignore the growing sense of dread, but he couldn’t shake the feeling that something was terribly wrong. He began to lose sleep, haunted by the whispers, by the words hidden beneath the numbers. Every time he closed his eyes, he could hear them.

And then, one night, the final transmission came through.

It was different this time—no numbers, just the whispers. They were louder than ever, clear and direct.

"They’re here."

David felt a cold sweat break out across his skin. He looked around the empty communications room, the air thick with tension. And then, for the first time, he heard the sound coming from outside the bunker. It was faint, like a low hum, but unmistakable.

He stood up slowly, his heart hammering in his chest, and walked to the door. The hum grew louder as he stepped outside into the night. The base was quiet, eerily still, but overhead, the sky seemed… wrong. The stars were there, but they flickered unnaturally, as if something massive were moving behind them.

David took a few steps forward, his breath catching in his throat as the hum intensified. And then, just beyond the trees, he saw them—tall, dark shapes moving silently through the fog.

For a moment, he couldn’t move, couldn’t think. The whispers filled his head, louder than ever, drowning out everything else.

"They’re here."

David ran.

The End.

Whispers in the Corn

Pete was a 58-year-old IT worker who had lived in Papillion, Nebraska, for as long as he could remember. His days were spent behind a computer screen, fixing problems and answering emails. Still, his evenings were his favorite part of the day. That's when he could relax with his wife, Janet, and their three tiny dogs—Sadie, Lola, and Darby. The dogs were his constant companions, always at his feet or curled up in his lap.

One hot August evening, after a long day of troubleshooting server issues, Pete took the dogs for a drive. The house felt stifling, and the dogs seemed restless. Janet waved him off, smiling from the porch as he loaded Sadie, Lola, and Darby into the back of his truck. He promised her they'd be back before dark.

As Pete drove down the familiar roads, the dogs eagerly poked their noses out of the open windows. The rolling fields of corn stretched endlessly on either side, swaying gently in the evening breeze. It was peaceful out here, with only the sound of crickets and the soft rumble of the truck.

After a while, Pete noticed a narrow dirt road he had never seen before. He slowed down, curiosity tugging at him. "What do you think, guys?" he asked the dogs, glancing in the rearview mirror. Sadie barked in response, and Pete chuckled. "All right, adventure it is."

He turned down the road, the truck bouncing over the gravel. The further he drove, the more isolated it felt. The corn grew tall and thick on both sides, towering over the truck like walls. The sun began to set, casting an orange glow across the sky, but something about the road felt off. The wind had died down, and the air was too still.

The dogs, who had been excited just moments before, grew quiet. Pete glanced over his shoulder and saw Sadie, Lola, and Darby sitting motionless, their ears perked, staring out the windows. A shiver ran down his spine.

He shook his head, trying to dismiss the unease creeping over him. "It's just a quiet night," he muttered to himself. But the further he drove, the more the road seemed to twist and turn in ways he didn't recognize. The corn was pressing in closer now, and Pete could have sworn it was moving, almost swaying toward the truck.

Suddenly, Sadie let out a low growl, her tiny body tense. Pete slowed the truck to a stop, squinting through the windshield. Up ahead, standing in the middle of the road, was a figure.

Pete's heart skipped a beat. The figure was tall and thin, draped in tattered clothes that seemed to blend with the darkening sky. It stood perfectly still, facing the truck, its face obscured by shadow.

"Who the hell…?" Pete muttered, gripping the steering wheel tighter. The dogs whined in the back, uneasy. He rolled down the window, calling into the fading light, "Hey! You need help or something?"

The figure didn't respond. It didn't move at all.

Pete's skin prickled with a sudden wave of dread. The dogs were whimpering now, their nervous energy filling the truck. He glanced at them, trying to reassure himself. "Maybe it's just some farmer," he said, though his voice wavered. But when he looked back up, the figure was gone.

His stomach dropped. There hadn't been any sound, rustling of the corn, or footsteps—just an empty road where the figure had stood moments before.

Pete's hands shook as he put the truck into gear, ready to turn back. But as he did, the radio crackled to life. Static filled the cab; beneath it, he could hear faint whispers, like someone—or something—was trying to speak through the noise.

"Pete… come… home…"

His blood ran cold. His name, clear as day, whispered through the static.

He slammed his hand on the radio, turning it off, but the whispers grew louder. The dogs were barking now, panicked, their tiny bodies pressed against the doors as if trying to escape.

The figure appeared again, this time on the side of the road. It stood just beyond the corn, its long arms reaching the ground, fingers twitching.

Pete's heart raced. His knuckles were white as he gripped the wheel. "What the hell is this?" he whispered, his voice barely audible over the pounding in his chest. He floored the gas, the truck lurching forward down the narrow road.

But the road didn't end.

No matter how far he drove, it twisted and looped, the cornfields on either side growing impossibly tall. The whispers in the air grew louder, circling around him, pressing in from all sides. He could hear them clearly now—dozens of voices chanting his name.

"Pete… come… home…"

His breath came in ragged gasps. The dogs were yelping, their fear palpable, but Pete's terror was overwhelming. The figure appeared again, this time ahead of him, standing in the middle of the road again.

Pete slammed the brakes, the truck skidding to a halt just feet from the figure. It bent forward slightly, its face still hidden in shadow, but Pete could feel its eyes watching him.

The whispers grew deafening, swirling around the truck, coming from the corn, air, and everywhere.

"Come home, Pete… come home…"

Pete screamed, throwing the truck into reverse. He spun the wheel, tires screeching as he turned around and sped back down the road. The figure didn't follow, but the whispers stayed with him, echoing in his ears and in his mind.

It felt like hours before Pete finally burst out of the cornfields and back onto the main road. The night was dark now, the cornfields behind him silent and still. The whispers had stopped, but Pete's heart still pounded.

When he pulled into his driveway, he barely registered Carol standing on the porch, her face filled with concern. He sat in the truck for a long moment, his hands trembling, the dogs whimpering softly in the back.

"What happened?" Carol asked, rushing to his side. But Pete couldn't find the words.

Later that night, after the dogs had calmed and Carol had gone to bed, Pete sat in the living room, staring into the darkness. He tried to tell himself it was all just his imagination, a strange, eerie night.

But in the silence of his house, he could still hear it.

"Come home, Pete… come home…"

 

The End.

BSIT400 - Week 2 Posting - What's the difference between a private cloud and a public cloud?

A private cloud is a cloud computing environment dedicated to a single organization, meaning all its resources, such as servers, storage, and networks, are used exclusively by that organization. It offers more control, customization, and security, making it ideal for businesses with specific regulatory or security requirements. Private clouds can be hosted on-premises or by a third-party provider.

In contrast, a public cloud is shared among multiple organizations, where resources are provided by a cloud service provider like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud. While public clouds are often cheaper and easier to scale, they offer less control than private clouds. Public clouds are commonly used for applications that require flexibility and scalability. Still, with shared resources, there may be concerns about data security or compliance.

Whether a private or a public cloud is better depends on the organization's specific needs. A private cloud is better for businesses prioritizing control, security, and customization. It's ideal for industries like healthcare, finance, or government that must comply with strict regulations. Since all resources are dedicated to one organization, it provides more control over data and infrastructure. Still, it can be more expensive to set up and maintain.

On the other hand, a public cloud is better for organizations that need flexibility, scalability, and cost-effectiveness. It allows companies to quickly scale up or down based on demand and only pays for the resources they use. While more affordable, the shared environment can raise concerns over data privacy and security.

Ultimately, the "better" option depends on the organization's size, security needs, and budget. Some businesses even choose a hybrid approach, using both cloud types for different workloads.

Reference:
Foundation, W. (2024, August 20). Cloud computing. Wikipedia. https://en.wikipedia.org/wiki/Cloud_computing


 

BSIT400 - Week 1 Posting - Introduction

Hello World! It is time for another series of blog postings related to my ongoing quest to complete the degree requirements for a Bachelor of Science Degree in Information Technology (BSIT). I am taking the BSIT400 "Cloud Computing & Governance Course" from Bellevue University this term. One of the requirements of this course is to post a series of blog entries related to the subject of this class, so keep an eye on this location for an exciting and thought-provoking discussion about all things Cloud!


If this is your first time here, my name is Pete, and I have been an IT professional for about 40 years. My specialty is Linux Engineering. I am a veteran of the USAF and have worked for various commercial entities, including Red Hat Inc. and Dell Inc. I am currently a contract IT Engineer for a principal defense contractor.
 

I have had some on-the-job experience with private and public clouds, and most of my work has been with VMWare and AWS products.

Status Update

 I just finished two more 12-week classes last Sunday: 

    BSIT340 - Cisco Routing Fundamentals

    BSIT350 - Microsoft Networking Fundamentals

Now I'm on a 12-week summer hiatus during which I will be working on Red Hat Linux Certifications. 

This fall/winter/spring terms I will be completing my remaining course requirements and be on-track to graduate after the 2025 Spring Term! 


Kafkaesque

"The term "Kafkaesque" is used to describe concepts and situations reminiscent of Kafka's work, particularly Der Process (The Trial) and Die Verwandlung (The Metamorphosis).[278] Examples include instances in which bureaucracies overpower people, often in a surreal, nightmarish milieu that evokes feelings of senselessness, disorientation, and helplessness. Characters in a Kafkaesque setting often lack a clear course of action to escape a labyrinthine situation. Kafkaesque elements often appear in existential works, but the term has transcended the literary realm to apply to real-life occurrences and situations that are incomprehensibly complex, bizarre, or illogical." (Franz Kafka 2024)


Example: "The United States of America has been very Kafkaesque from 2020-2024."

Wikimedia Foundation. (2024g, March 28). Franz Kafka. Wikipedia. https://en.wikipedia.org/wiki/Franz_Kafka


BSIT380 - Week 12 Post - Happy Trails to You, until we meet again.

BSIT 380 - System Hardening and Network Risk Management

As my current class ends, I'd like to thank whoever took the time to read all of my blog posts that, although required for the class, were still enjoyable to research and write. The name of the class is "System Hardening and Network Risk Management", which explains all of the cybersecurity and server references throughout the blog posts. I chose to write on a variety of topics, mostly revolving around the class topics for that particular week. Internet searches with Google.com and Bing.com provided most of the source material for my posts. It also helped that I have been working in the Information Technology field for the past 40 years. I hope this Blog's content was helpful to any information security professional who happens to stumble across it in my little corner of the internet. And here is a free "lesson learned" that I figured out while doing this: use Grammarly.com to write your blog posts. Let it teach you correct spelling and grammar. First impressions count.

BSIT 380 - Week 11 Posting - What is an Incident Response?

In cybersecurity, an "incident response" refers to the organized approach to addressing and managing the aftermath of a security breach or cyberattack, also known as a security incident. The goal is to handle the situation in a way that limits damage and reduces recovery time and costs. An effective incident response plan is critical to any organization's cybersecurity strategy and includes the elements of preparation, identification, containment, eradication, and recovery.

Preparation is the foundation of incident response. It involves setting up an incident response team, defining their roles and responsibilities, and developing a response plan. Identification consists of detecting and determining whether a cybersecurity event is a security incident, which requires practical monitoring tools and awareness to recognize signs of a potential breach, such as unusual system behavior, alerts from security tools, or reports of suspicious activity. Once an incident is confirmed, the immediate goal is containment, limiting its scope and preventing further damage. After containment, the next step is to find and eradicate the incident's root cause, which may involve removing malware, deactivating breached user accounts, or fixing vulnerabilities. In recovery, affected systems are restored and returned to regular operation. This process must be carefully managed to avoid reintroducing the threat. It often includes validating systems functioning normally and monitoring for any signs of compromise.

After the incident is resolved, conducting a post-incident review is crucial,  analyzing what happened, how it was handled, what worked well, and what could be improved. The insights strengthen the incident response plan and overall security posture.

BSIT380 - Week 10 Post - Automating data enrichment at scale

 In the fast-paced realm of cybersecurity, automating data enrichment at scale is a game-changer. Data enrichment is the process of enhancing raw data with additional context and information, transforming it into a more meaningful, actionable form. In cybersecurity, this means taking vast amounts of data from diverse sources—like system logs, network traffic, security device outputs, and external threat intelligence—and augmenting it with extra layers of detail. The objective is clear: to provide deeper insights and a clearer understanding of the cyber threats lurking in the data. However, given the data's sheer volume and complexity, manually sifting through it is akin to finding a needle in a haystack. This is where automation steps in, leveraging advanced tools and technologies to process and analyze this data efficiently, ensuring that the valuable nuggets of insight are found and utilized effectively and timely.

Automating data enrichment involves several sophisticated techniques. First, it employs big data technologies like Hadoop or Spark, which can handle and process large datasets at high speeds. Machine learning and artificial intelligence play a pivotal role, too, in identifying patterns and anomalies that might indicate potential security threats—a task too intricate and vast for human analysts to perform consistently and accurately. Another critical aspect is the integration of real-time threat intelligence. This involves enriching internal data with up-to-date information about emerging threats from around the globe, adding crucial context, and aiding in quickly identifying potential risks. All of this is wrapped up in an environment that emphasizes scalability and flexibility, often leveraging cloud-based solutions to adapt to the ever-changing volume and nature of data. Ultimately, automating data enrichment in cybersecurity isn't just about handling data more efficiently; it's about staying one step ahead in a world where cyber threats evolve just as quickly as the technology we use to combat them.


Reference:

Nachaj, A. (2024, January 29). Data enrichment: The holy grail of the Cybersecurity Industry. Metron Security Blogs. https://hub.metronlabs.com/data-enrichment-the-holy-grail-of-the-cybersecurity-industry/

BSIT380 - Week 9 Post - Fortifying Your Server Against Brute-Force Attacks: Essential Strategies

Hello, computer security nerds! Today, I'm talking about protecting your servers against brute-force attacks. These persistent threats can compromise your server's security. Here are some strategies to bolster your server's defenses:

1. Crafting a robust Password Policy
A robust password is your first line of defense. Opt for lengthy and complex passwords that mix various character types. The goal is to make them difficult to guess but still memorable. Avoid dictionary words, personal info, and recycled passwords – remember, creativity is vital.​ If possible, use lengthy passphrases which are easier to remember. And stop writing down your passwords unless you're keeping your notebook in a locked security container of some type...

2. Login Attempt Limitations
Limiting failed login attempts is crucial. Implement a system that blocks IP addresses after several unsuccessful tries. However, be cautious – you don't want to lock out legitimate users accidentally.​

3. The Art of Progressive Delays
Here's an interesting twist: Use progressive delays instead of outright account lockouts. Each failed attempt increases the wait time, frustrating potential attackers and slowing down their efforts​

4. CAPTCHA: More Than Annoying Squiggles
Integrating CAPTCHA challenges helps differentiate bots from humans. Although they can be a bit of a nuisance, they're incredibly effective against automated brute-force attempts​
​​
5. Two-Factor Authentication: Doubling Down on Security
Adding a second layer of security, like a code sent to a mobile device, significantly enhances your protection. It's a simple yet effective barrier against brute-force attacks.​

6. Vigilant Monitoring: Keeping an Eye Out
Regularly scan your server logs. Look for patterns that suggest a brute-force attack, such as repeated failed logins from the same IP address or various addresses trying the same account​.

7. Shaking Up Defaults: Ports and Usernames
Changing default ports and admin usernames can dramatically reduce the success rate of attacks. It's a small change with a significant impact – a tactic often overlooked but highly effective.​ Just ensure you keep excellent documentation on which ports are now in use!
​​
8. Network-Level Guardians: Firewalls and IDS/IPS
Deploy network-level security measures like firewalls and intrusion detection systems. They're your digital sentinels, guarding against suspicious traffic​​.

9. Keeping Software Up-to-Date: A Continuous Process

Last but not least, ensure all server software and applications are regularly updated with the latest security patches. Staying current is staying safe.

In Summary:
Combining these strategies forms a formidable defense against brute-force attacks. While no single method is completely foolproof, a layered approach significantly reduces risk. Stay vigilant, stay updated, and remember, the best defense is proactive.

BSIT380 - Week 8 Post - Controlling Application Execution with Whitelisting and Blacklisting

In the ever-evolving landscape of cybersecurity, controlling which applications can run on a network or a device is very important. It can be effectively managed through two contrasting approaches: application whitelisting and blacklisting.

 

Application Whitelisting: This approach involves creating a list of authorized applications permitted to run on a system. Any software not included in this whitelist is automatically blocked. This method is highly secure as it prevents unknown or potentially harmful applications from executing. However, it requires thorough knowledge of all the necessary applications for business operations. It can be restrictive, as any new application needs explicit approval before it can be used.

 

Application Blacklisting: In contrast, blacklisting involves creating a list of applications that are forbidden. Any application not on this blacklist is allowed to run. This method is more flexible and less resource-intensive than whitelisting, as it doesn't require a comprehensive list of all acceptable applications. However, it's less secure, as it can't block unknown threats - any new malicious software not already on the blacklist can run unhindered.

 

Best Practices:

  • Regular Updates: Keep the whitelist or blacklist updated with the latest application information.
  • User Training: Educate users about the risks of unauthorized applications.
  • Monitoring and Auditing: Regularly monitor application usage and audit the lists for effectiveness.
  • Balancing Security and Flexibility: Find the right balance between security (whitelisting) and flexibility (blacklisting) based on your organization's needs.

Conclusion: Both whitelisting and blacklisting have their merits and drawbacks. While whitelisting offers a more secure environment by only allowing pre-approved applications, it can be rigid and resource-intensive. Blacklisting, while more flexible, might leave systems vulnerable to new or unknown threats. The choice between them should be based on the organization's specific requirements and risk profile. Remember, effective application control is a critical component of cybersecurity strategy and should be tailored to fit the unique needs of your network environment.

BSIT380 - Week 7 Post - An article about flow analysis for cybersecurity...

The insightful blog entry "Flow Analytics for Cyber Situational Awareness" by Sid Faber, hosted on Carnegie Mellon University's Software Engineering Institute's Insights blog, focuses on the critical role of network flow analytics in enhancing cybersecurity. Faber delves into how network flow analysis is a foundational tool for organizations to achieve cyber situational awareness, especially during high-stress times like the holiday season when data centers face surges in online activity. The ability to distinguish between a legitimate increase in business traffic and potential cyber threats like denial-of-service attacks hinges on understanding the intricate patterns of network flow. This understanding is vital for organizations to respond effectively to immediate challenges and predict and prepare for future cyber events.

Faber's article emphasizes the importance of a three-step model in achieving situation awareness in cybersecurity:

  • Perception or sensing of the environment
  • Comprehension of the sensed information
  • Projection of future states of the environment

This model, rooted in the work of Dr. Mica Endsley, is particularly relevant in the cyber domain, where understanding the flow of network traffic is crucial. Organizations can gain valuable insights into how their networks are utilized by analyzing network flow data, enabling them to detect anomalies and potential security threats. The article underscores the need for effective analytics presentation to decision-makers, ensuring that complex data is translated into actionable intelligence. This approach is about detecting threats and shaping a proactive cybersecurity strategy that aligns with the dynamic nature of the digital world. To read the full article, visit Sid Faber's blog post.

 

Faber, S. (2015, December 7). Flow analytics for cyber situational awareness. SEI Blog. https://insights.sei.cmu.edu/blog/flow-analytics-for-cyber-situational-awareness/